Google recently hung a ‘going out of business’ sign on its Message Continuity service for users of Microsoft Exchange. Google will continue to provide the service to its users until their contracts run out, but after that, they’re on their own.

Since the service was launched a little over a year ago, “hundreds” of businesses have subscribed to the offering, which uses Google’s cloud to provide email continuity when a Microsoft Exchange environment is interrupted for any reason.

Hundreds of users, though, can’t compete with the “millions” of businesses that have moved their entire email operation to Google Apps, so Searchzilla has decided to scrap its continuity product for Exchange  and concentrate all its resources on its application suite.

Current users of the continuity product were “encouraged to consider using Google Apps as their primary messaging and collaboration platform” in a company blog written by Vice President of Product Management Dave Girouard.

The brusque departure by Google from the Exchange disaster recovery scene contrasts sharply with how it entered it:

“Google Message Continuity advances our commitment to providing rapidly deployed, cost-effective email management solutions for organizations of all sizes,” Enterprise Product Manager Matthew O’Connor wrote when the continuity product was announced.

Looking back on the announcement, it appears that Google’s “commitment” to the Exchange market was as solid as an adolescent’s commitment to the latest fad.

That’s not to say that Google’s intentions in offering an Exchange product weren’t clear from the start for careful readers of the company’s pronouncements. “Additionally, for organizations interested in eventually moving to Google Apps, Google Message Continuity can provide a smooth bridge to the cloud,” O’Connor slyly observed in his blog item.

O’Connor’s colleague, Rajen Sheth, the group product manager for Google Apps had a similar pitch at the time:

“Google Message Continuity can also help organizations transition to Google Apps down the road,” he wrote. “Since Microsoft Exchange and Gmail are always in sync with one another, there’s no need to migrate email data when eventually deploying Google Apps.”

Little did those who signed on for Google’s continuity solution realize when they did so that if they didn’t “transition” to Google Apps fast enough to suit the Ferret King, they’d be left looking for another business interruption solution within a year’s time.

Google has been criticized in the past for its flighty attitude toward product development. Some detractors maintain that Google often enters markets to be disruptive, not competitive. Like a sea gull boss, it will undercut competitors in a market and when things don’t work, abandon that market, leaving customers who had faith in the Google brand to clean up the mess.

That kind of product management may work with consumers, but it leaves something to be desired in the business world. Google’s competitor in the enterprise market, Microsoft, knows that. While the Redmond crew have suffered a few slings and arrows for sticking with products too long, their commitment to legacy products has been an important, if sometimes overlooked, part of their success in the business market.

Google’s forsaking of Message Continuity brings to mind some remarks by Microsoft Senior Director of Online Services Tom Rizzo in his famous “Google Graveyard Spooks Customers” blog written on Halloween last year:

“Google releases experimental products and tracks adoption to determine whether to continue providing them,” he wrote. “Its products are like spaghetti, Google throws them up against the wall to see if they stick.”

“The burials of de-supported products are more examples of what is convenient for Google and not good for business,” he added.

Google Deserts Exchange Users by Killing Message Continuity

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

Downtime in minutes in major email programs.

Google would like to replace Exchange as the primary email platform in corporate America but, as the song goes, you can’t always get what you want. So the search giant has adopted a backdoor approach to grabbing business from Exchange users. It has launched a service aimed at those users that offers to backup their email to Google’s cloud.

The service, Google Message Continuity, will back up Exchange mailboxes for an annual fee of $25 per user. Only Exchange 2003 and 2007 are supported now, but a version for Exchange 2010 is in the wings.

Google Message Continuity works like this.

Accounts on an Exchange server–including email, calendar and contacts–are mirrored on Google’s Gmail servers. If the Exchange server’s operation is interrupted for any reason–a breakdown, for instance, or scheduled maintenance–users can log on to Gmail, using their Exchange username and password, and continue to send and receive email. Since both systems will be synchronized, users can switch between the two without a hiccup.

While others offer similar Exchange solutions, Google believes it has a leg up on them because its size allows it to more aggressively price its service and it’s better equipped to take advantage of Gmail’s architecture for providing a seamless solution. In addition, Exchange’s openness makes it easy to plug something like the service’s synchronization server into it. In fact, IT pros should be able to integrate the service through an Exchange plug-in that can be installed without any outside support.

Google has been taking potshots at other email solutions for years. As far back as 2008, it boasted of its 99.9 percent reliability rate. That amounts to 10-15 minutes a month. “That 10-15 minutes per month average represents small delays of a couple of seconds here and there,” it asserts.

Citing research from the Radicati Group, Google says companies with on-premise email solutions averaged 30-60 minutes a month in unscheduled downtime and an additional 36-90 minutes a month in planned downtime.

“Looking just at the unplanned outages that catch IT staffs by surprise, these results suggest Gmail is twice as reliable as a Novell GroupWise solution, and four times more reliable than a Microsoft Exchange-based solution that companies must maintain themselves,” it notes.

“Gmail’s reliability jumps to more than four times as reliable as a GroupWise solution and 10 times more reliable than an Exchange-based solution if you factor in the planned outages inherent in on-premises messaging platforms,” it adds.

And of course, there’s the bottom line card. Email downtime can cost a company with 500 employees as much as $90,000 a year.

As good a game as Google talks, there’s plenty to give administrators pause about turning over control of their precious data to the company. Security transparency, for instance, is a concern. Technical support is another friction point. Bragging about how easy your apps are to use is one thing; responding to problems in a timely fashion when they’re being used is quite another.

Of course, Microsoft has its own cloud that it has invested quite a bit of money in. Its 23 data centers, built at a cost of $500 million each, are located around the world to offset any disasters that might occur at a particular locale. Administrators concerned about the performance of their local versions of Exchange, could take advantage of Microsoft’s Exchange in the cloud offering. Because that service creates multiple copies of a user’s data, email downtime is practically zero.

Nevertheless, Google’s move to wean enterprises away from Exchange by giving them a taste of Gmail through a backup solution can be a clever move. It gives Google a chance to prove itself to Exchange users and accumulate street cred with them. Once an organization becomes comfortable with Google as a partner, it might consider giving the search firm a bigger piece of its email pie or deserting Exchange all together.

In recent weeks, Google has perked up its efforts to woo Microsoft corporate customers to the search firm’s cloud. Last month, for instance, it announced a test version of Google Cloud Connect , which allows Microsoft Office 2003, 2007 and 2010 users to sync their documents with Google’s cloud apps from within the Microsoft suite. Once in Google apps, documents can be shared and even simultaneously edited without leaving Office.

Google’s maneuvers may bear some fruit, but it’s tough to change the mindset of administrators. What’s more, Microsoft won’t be standing on the sidelines watching the game that Google’s playing. It’s prepared to do what it takes to preserve its Exchange turf.

Google offers backup service for Exchange

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

Backup and archive. What’s the difference? Even people inside of IT sometimes see these two things as being the same, to the detriment of their organization. An article on Shortinfosec.net explains the difference well, and highlights the importance of including both backup and archiving in your IT infrastructure. Failing to make the distinction could cause you to choose an incorrect media, or have inadequate restore time relative to what your users need to do.

Right off the bat, the article gives an excellent example of a company undergoing an audit. After showing their backup system, they were asked about their archive, after which they pointed to their backup tapes–but the backup tapes were rotated every six months. Therefore, although the company had backup, they really had no archive. So what’s the difference? Backup is meant to create a copy of the current state, which can be used to restore a system, or a previously saved copy of a document, very quickly with a minimum of search requirement. An archive, on the other hand, is generally considered a historical reference that would be accessed less frequently. Backup and archive serve different purposes, and therefore may require different media.

One point in the article however, in describing the criteria for backup and archive solutions, states that backup needs to be easily accessible, while archives can have slower access, and to a degree this may be true. However, it’s not really necessary given the state of some of today’s archiving solutions. Traditional PST files for example, are a cumbersome way of archiving emails. And with increased reliance on information–including older information–workers are having to go back into archives more frequently and will be dependent on easy access. I still remember asking the IT guy for an old file, which meant I had to fill out a form, which got put on the bottom of a stack on his desk. And when he got around to it, he would send somebody into an air conditioned room full of tapes to hunt around for the one I needed. The process took days. Today, this scenario is totally unacceptable and unnecessary, and there’s no reason for relying on a third party IT guy to gain access to an archive. Ideally, it should be accessible from the desktop, and should be easily searched.

The difference between backup and archive

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