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

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

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.

What is the Maximum Drives for an EC2 Windows Instance? - EBS Volume Limit

Yesterday while I was doing some performance testing on Amazon EBS (elastic block storage) volumes attached to a Windows AMI (Amazon machine instance) I ran into an unanticipated issue - the maximum number of drives associated with an EC2 Windows server was lower than I expected.  The max connected drives is 12 - this includes both ephemeral drives and EBS volumes.  This is a little bit of a surprise, especially since Linux instances are supposed to handle 16.

NOTE: This article is about instance-store instances.  For information about drive limitations on EC2 Windows EBS-backed instances see, "Maximum EBS Volumes on EC2 Windows EBS-backed Instances."

I haven't run across this little tidbit anywhere, nor could I find it today when specifically searching for it, so I thought I'd post a few details about my findings.

First off, yesterday I spun up an Extra Large Instance (AKA m1.xlarge) and created a dozen or so 5GB EBS volumes and began attaching them to the instance.  Since I was creating several I used the EC2 command line tool ec2-create-volume:

ec2-create-volume -s 5 -z us-east-1d

In the preceding command the "-s 5" creates a 5GB volume and "-z us-east-1d" creates the volume in the specified Amazon Availability Zone, which by the way, has to match that of the instance to which you will attach the volume.

I attached some volumes using ElasticFox. . .

. . . then attached some with the EC2 command line tool ec2-attach-volume:

ec2-attach-volume vol-0d62c264 -i i-999919f2 -d xvdk
ec2-attach-volume vol-0362c26a -i i-999919f2 -d xvdl
ec2-attach-volume vol-0562c26c -i i-999919f2 -d xvdm

Doing this particular task isn't for the faint of heart as you have to specify the device name (-d xvdm, for example) which has to be unique for each volume attached to a server instance.  You may find it easier generally to use ElasticFox or the AWS Management Console.

Let me take just a moment to point out that, depending on the instance type, you will already have two or more drives.  For example the instance I used here, m1.xlarge, has a 10GB "C drive," and four 420GB drives, D, E, F & G (by default) in Windows.  In Windows Disk Management these will be disks 0-4.  As you add an EBS volume it will be Disk 5, and so on.

I actually attached five EBS volumes in one fell swoop from the command line, and much to my chagrin I immediately lost connectivity to my instance - I had an RDP session open at the time which immediately quit responding.

Since I lost connectivity to the instance and couldn't re-establish a Remote Desktop connection I manually rebooted the instance with ElasticFox.  However, this didn't work.  Initially I thought I had overlapped a device name which the instance couldn't handle so I detached the five EBS volumes previously attached from the command line and rebooted the instance.  I was overjoyed when I was able to login again.

Next I set about to more carefully attach the volumes, which I did one at a time with ElasticFox.  Again, after attaching the five additional volumes my instance stopped responding.  At this point I wasn't sure if I had reached the limit of attached volumes, if one or more volumes had some sort of problem, or if someone at Amazon was messing with me.  I had to find out so I did some testing. . .

I starting running a continuous ping (tcping actually) to the instance (so I would know if/when it crapped out and when it was back online after rebooting) and set about testing connecting EBS volumes to the instance. Sure enough, every time I connected too many EBS volumes the instance would hang.  I wanted to test this against instances with more (and less) ephemeral drives so I also started up a Small Instance (AKA m1.small) and the mack-daddy of them all a High-Memory Quadruple Extra Large Instance (AKA m2.4xlarge).  These two instance types come "out-of-the-box" with two and three drives each, respectively.

Don't believe me on the m2.4xlarge instance?

So, with all three server types, m1.small, m1.xlarge and m2.4xlarge running Windows the magic number of (total) drives was 12 before I started having problems.  An interesting note is that you can actually add a 13th drive and everything appears to be fine.  It's when you add the 14th drive that all hell breaks loose & you instantly lose access to the instance.  Once this happens you have to detach two volumes then forcibly reboot the instance before it starts to respond.  It certainly is good that you can at least regain access.

Remember how I said everything appears to be fine after adding the 13th drive?  Well, appearances aren't everything. . .  What I found was that although you could connect the 13th drive/volume & the instance seems fine, when you reboot it the instance doesn't come back online.  I had to detach the 13th drive then forcibly reboot the instance before I could connect.

Another interesting note is that the device names went up to xvdp (which is actually displayed as the highest device letter when attaching volumes in ElasticFox) then started back at xvdf.

Device range when attaching volumes in ElasticFox:

Attached EBS volumes:

The bottom line is that through a little work yesterday and today I was able to determine definitively that Windows instances (at least instance-store, or S3-backed instances running Windows 2003 - not sure about Windows 2008 on EBS-backed storage) cannot have more than 12 total drives attached.

See also:

• ElasticFox Firefox Plugin for Amazon EC2
• Installing EC2 Command Line Tools on Windows

Elasticfox Firefox Extension for Amazon EC2

I've been using ElasticFox for a while now and thought I'd jot down a few notes about it.  I don't use it exclusively to manage my Amazon Web Services (AWS) EC2 instances, EBS volumes, etc., but usually I do go there first.  It's worth mentioning that I also use the AWS Management Console and EC2 command line tools (both in Windows and Linux).  Typically I keep ElasticFox open as I access it several times a day.

One of the best things about ElasticFox is that you can add "Tags" to instances, EBS volumes, etc.  Tags are your own notes about the instance, like a friendly name.  I really wish Amazon had a field like this that was tied to the instance so it would be available in all tools.  One minor draw-back to tags are that they only apply to the particular browser in which they are created.  They don't, for example, if you logon as a different user to your machine, or on other machines.

With ElasticFox you can connect to various regions, even with different credentials.  It allows you to manage the following by selecting the appropriate tab:

• Instances
• Images
• KeyPairs
• Security Groups
• Elastic IPs
• Volumes and Snapshots
• Bundle Tasks
• Reserved Instances
• Virtual Private Clouds
• VPN Connections
• Availability Zones

Read more about and download the Elasticfox Firefox Extension for Amazon EC2 and enjoy.

See also Copying ElasticFox Tags from One Browser to Another.

UPDATE:

ElasticFox doesn't support versions of FireFox above 3.x, so get Elasticfox (for EC2 Tag) which adds a few more nice features.

Ping Amazon EC2 Server Instances - How To

By default Amazon EC2 instances don't respond to ICMP requests, i.e. ping.  Of course there are several reasons why one may want to ping an Amazon EC2 instance, including verifying if it is online and to test latency.  As with most things there is more than one approach to this issue.

First, you could enable ICMP through Amazon security groups.  This can be done easily with the Amazon Management console, ElasticFox or EC2 command line tools.  You could open it up to the whole world:

ec2-authorize default -P icmp -t -1:-1 -s 0.0.0.0/0

. . . or, specific IP addresses or ranges:

ec2-authorize default -P icmp -t -1:-1 -s <IP Address>

Another approach would be to use TCPing (works with both Linux and Windows - see Ping Over TCP with tcping.exe in Windows or tcping for Linux).  I like to use this method because you can test general connectivity over specific ports.  For example you could use

tcping ec2-75-101-206-107.compute-1.amazonaws.com

to test connectivity to the specified server over the default port 80.  Or you could specify a port, like 22 for SSH or 3389 for RDP:

tcping ec2-75-101-206-107.compute-1.amazonaws.com 22

One method I use to determine when an EC2 instance that is first starting comes online, or when a restarting instance is again online (either from a reboot or bundling the EC2 instance), is to use tcping to send a ping continuously every second.  You could use the command:

tcping -t -i 1 ec2-75-101-206-107.compute-1.amazonaws.com

This very useful as you can essentially track the progress of the instance coming online, then becoming available.  At first you will receive the message, "Connection timed out. . ."  This indicates that tcping is not getting a response at all, i.e. that the instance cannot be reached.  Once the instance starts, but the OS isn't fully available the message, "Connection refused. . ." will be the result.  This means tcping can reach the machine (the network card and TCP/IP stack are available), however, the port you are probing, 80 in this case, isn't accepting connections.  Then, when it's available (on the specified port) it will respond with the message, "Port is open. . ."

I like to use the interval of 1 second as it is useful in determining how long an instance was offline and the duration of each stage.

For more info see the following posts.

• Installing EC2 Command Line Tools on Windows
• Ping Over TCP with tcping.exe in Windows
• tcping for Linux