Using Windows Server Backup to Back Up and Restore Exchange Data

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1.

Microsoft Exchange Server 2007 Service Pack 2 (SP2) includes a new plug-in that enables you to make Volume Shadow Copy Service (VSS)-based backups of Exchange data using Windows Server Backup in Windows Server 2008. You can use Windows Server Backup to back up and restore your Exchange 2007 SP2 databases. A thorough understanding of what needs to be backed up, where to store backups, and how to restore backups is key to being an effective Exchange administrator. For more information about what needs to be backed up in Exchange 2007, see What Needs to Be Protected in an Exchange Environment.
The new plug-in is delivered in the form of a single executable called WSBExchange.exe. This plug-in is automatically installed by SP2 on all Exchange 2007 Mailbox servers. The plug-in enables Windows Server Backup to be able to make Exchange-aware VSS backups. Before using Windows Server Backup and the Exchange plug-in to back up Exchange data, we recommend that you familiarize yourself with the following features and options for the plug-in:

  • Backups are VSS-based only. You cannot make streaming ESE backups using Windows Server Backup with or without the plug-in.
  • Backups taken with Windows Server Backup occur at volume level. To back up a storage group and database, you must back up the entire volume containing the storage group and database. You cannot back up any data without backing up the entire volume containing the data.
  • The backup must be run locally on the server being backed up, and you cannot use the plug-in to take remote VSS backups. There is no remote administration of Windows Server Backup or the plug-in. You can, however, use Remote Desktop or Terminal Services to remotely manage backup.
  • The backup can be created on a local drive or on a remote network share.
  • Only Full backups can be taken. Log truncation will occur only after a successful completion of a full backup of a volume containing an Exchange storage group and database.
  • In a continuous replication environment, only volumes that contain active database copies can be backed up by using the plug-in.
  • When restoring data, it is possible to restore only Exchange data. This data can be restored to its original location or to an alternate location. If you restore the data to its original location, Windows Server Backup and the plug-in will automatically handle the recovery process, including dismounting any existing databases and replaying logs into the recovered database.
  • The restore process does not directly support the Recovery Storage Group (RSG). However, if you restore to an alternate location, you can then manually move the restored data from the alternate location into an RSG, if needed.
  • When restoring Exchange data, all backed up storage groups must be restored together. You cannot restore a single storage group or database.
  • The plug-in does not support the Exchange Replica VSS Writer that is part of the Replication service. As a result, you cannot use Windows Server Backup to backup passive copies of storage groups.

For detailed steps about how to back up an Exchange server using the SP2 plug-in for Windows Server Backup, see How to Perform a Backup of Exchange Using Windows Server Backup.
For detailed steps about how to restore data from a backup taken with the SP2 plug-in for Windows Server Backup, see How to Restore a Backup of Exchange Using Windows Server Backup.


Convert VMDK VMware to VHD Virtual Server Files

Convert VMDK VMware to VHD Virtual Server Files using Vmd2Vhd tool from vmToolkit.

Here’s an article with details.


Find Local Open Ports on Windows 7, 2008 & Earlier Versions as Well

The NETSTAT command can be used to find all “listening” and “established” ports on your Windows computer.  From a command prompt run:

netstat -an |find /i "listening"  OR  netstat -an |find /i "established"

To see all open, established, closing and other used ports type:

netstat -a

Apple iPad

How To Print From an iPad

Having trouble printing from your iPad?  This is the easiest way to print from and Apple iPad.  It’s so simple a caveman could to it.


Barack Obama, “Leveling the Playing Field”

Trickle-up Poverty

Amazon Web Services AWS ElasticFox

Maximum EBS Volumes on EC2 Windows EBS-backed Instances – EBS Volume Limit

Last week I wrote about The Maximum (EBS) Drives/Volumes for an EC2 Windows Instance.  In that I discussed the max I had discovered was 12.  While that is accurate, it is important to understand that was based on “instance-store” (or S3-backed) instances.  Since I’ve been working recently with EBS-backed Windows (2003 and 2008) instances I wanted to see what they could handle.

I started by creating about a dozen EBS volumes, then using ElasticFox I attached them to my Windows instance.  ElasticFox will auto-assign the device name – xvdh, xvdi, xvdj, and so on up to xvdp.  After that it will begin using xvdg, xvdf, xvde, etc.  After I had 14 total drives (Amazon calls them volumes, Windows calls them drives – therefore I am using the terms interchangeably) attached I received the message, “The request must contain the parameter device” and couldn’t attach any more.

Next I turned to Amazon’s AWS Management Console which displays a list of available devices.  However, it only displays xvdf – xvdp.

Since xvdd – xvdp were already in use, and I reasoned that the root volume was using xvda, I tried to manually use xvdc, and it worked.  I was also able to manually assign device xvdb.

At this point I had 16 EBS volumes (drives 0-15) attached to my Windows instance.

I was able to successfully reboot the instance and everything worked fine, unlike when I lost connectivity to the instance-store instance as described in my previous post.

Just for fun I tried to device names outside the specified range.  For example when I tried to use xvdq I received the message, “Value (xvdq) for parameter device is invalid.  xvdq is not a valid EBS device name.”

This all makes sense as “p” is the 16th letter in the alphabet.  Therefore, devices xvda – xvdp are available and usable on Windows 2003 and Windows 2008 Amazon EBS-backed instances.


Google Changes Name to Topeka

You aren’t in Google any more. . .

Early last month the mayor of Topeka, Kansas stunned the world by announcing that his city was changing its name to Google. We’ve been wondering ever since how best to honor that moving gesture. Today we are pleased to announce that as of 1AM (Central Daylight Time) April 1st, Google has officially changed our name to Topeka.

We didn’t reach this decision lightly; after all, we had a fair amount of brand equity tied up in our old name. But the more we surfed around (the former) Topeka’s municipal website, the more kinship we felt with this fine city at the edge of the Great Plains.

In fact, Topeka Google Mayor Bill Bunten expressed it best: “Don’t be fooled. Even Google recognizes that all roads lead to Kansas, not just yellow brick ones.”

For 150 years, its fortuitous location at the confluence of the Kansas River and the Oregon Trail has made the city formerly known as Topeka a key jumping-off point to the new world of the West, just as for 150 months the company formerly known as Google has been a key jumping-off point to the new world of the web. When in 1858 a crucial bridge built across the Kansas River was destroyed by flooding mere months later, it was promptly rebuilt — and we too are accustomed to releasing 2.0 versions of software after stormy feedback on our ‘beta’ releases. And just as the town’s nickname is “Top City,” and the word “topeka” itself derives from a term used by the Kansa and Ioway tribes to refer to “a good place to dig for potatoes,” we’d like to think that our website is one of the web’s top places to dig for information.

In the early 20th century, the former Topeka enjoyed a remarkable run of political prominence, gracing the nation with Margaret Hill McCarter, the first woman to address a national political convention (1920, Republican); Charles Curtis, the only Native American ever to serve as vice president (’29 to ‘33, under Herbert Hoover); Carrie Nation, leader of the old temperance movement (and wielder of American history’s most famous hatchet); and, most important, Alfred E. Neuman, arguably the most influential figure to an entire generation of Americans. We couldn’t be happier to add our own chapter to this storied history.

A change this dramatic won’t happen without consequences, perhaps even some disruptions. Here are a few of the thorny issues that we hope everyone in the broader Topeka community will bear in mind as we begin one of the most important transitions in our company’s history:

  • Correspondence to both our corporate headquarters and offices around the world should now be addressed to Topeka Inc., but otherwise can be addressed normally.
  • Google employees once known as “Googlers” should now be referred to as either “Topekers” or “Topekans,” depending on the result of a board meeting that’s ongoing at this hour. Whatever the outcome, the conclusion is clear: we aren’t in Google anymore.
  • Our new product names will take some getting used to. For instance, we’ll have to assure users of Topeka News and Topeka Maps that these services will continue to offer news and local information from across the globe. Topeka Talk, similarly, is an instant messaging product, not, say, a folksy midwestern morning show. And Project Virgle, our co-venture with Richard Branson and Virgin to launch the first permanent human colony on Mars, will henceforth be known as Project Vireka.
  • We don’t really know what to tell Oliver Google Kai’s parents, except that, if you ask us, Oliver Topeka Kai would be a charming name for their little boy.
  • As our lawyers remind us, branded product names can achieve such popularity as to risk losing their trademark status (see cellophane, zippers, trampolines, et al). So we hope all of you will do your best to remember our new name’s proper usage:

Finally, we want to be clear that this initiative is a one-shot deal that will have no bearing on which municipalities are chosen to participate in our experimental ultra-high-speed broadband project, to which Google, Kansas has been just one of many communities to apply.

Posted by Eric Schmidt, Chairman and Chief Executive Officer, Topeka Inc.