Devin on Earth

[Edited 12/12/2007 to correct KB/MB error in the log file sizes; thanks to Chris Scharff for catching it.]

Recently, I’ve seen a couple of pieces of misinformation about Exchange 2007 and DPM floating around in the ether. Rather than let them go uncontested, I figured I’d mention them here and give them the good puncturing they deserve:

• Exchange 2007’s continuous replication features rely on backup and restores. Um, wow. This is so wrong I can’t even begin to figure out what mistake in understanding brought this one about. The continuous replication options (LCR, CCR, and SCR) rely on log shipping — the process of taking the transaction logs from one copy of the protected mailbox database and sending them to another copy. Here’s the key thing: this process is not backup and restore. True, copying outstanding transaction logs is a necessary part of an Exchange backup strategy, but an Exchange backup is also taking copies of the mailbox database files directly. Remember how Exchange uses transaction logs:
  1. A write operation is generated by Exchange, such as when a new message is placed in a mailbox or a client makes an update to a message property.
  2. The operation is written sequentially to the next open transaction log file (these files are always 5MB in size in Exchange 2000/2003, 1MB in size in Exchange 2007). Note that this sequential write is performed to increase disk performance.
  3. The write operation is marked as complete and Exchange moves on to the next operation. It has not, however, yet been written to the database!
  4. At some later time, Exchange takes the queued-up write operations and applies them, in order, to the actual mailbox database. This is a random write operation, which in turn requires more seek operations (and is slower), so Exchange tries to make this happen when there’s less I/O on the database.

• Continuous replication options don’t protect against database corruption. Again, no. If you take a look at the process I just talked about for the previous point, you should see why this second myth is also false. Each I/O operation is written to the transaction log first, then applied to the database at a later point in time. If you ship the transaction log files to a second replica, that replica is recreating its own copy of the database. It’s not a bit-for-bit copy of the source Exchange database; it’s an independent re-creation. The particular hardware and load conditions that contribute to any given database corruption on the source database don’t exist on the target database.
• DPM doesn’t do block-level copies; it’s just copying Exchange data as a file copy. Well, this is true if you’re using DPM 2006; it doesn’t have native support for Exchange, so you first have to use something like NTBackup to dump the database to a file on disk, which DPM 2006 can then protect.

  In DPM 2007, however, this all changes — you now have native Exchange support. Not only will DPM 2007 do direct copies of your Exchange databases at the disk block level, ensuring that only the blocks that have changed are synchronized, but it also watches the transaction logs and copies them to. DPM essentially keeps another replica of your protected databases in its storage pool, which means you have a restore granularity unmatched by conventional backup programs.

Now that Exchange 2007 SP1 is here, more and more people will be deploying Exchange 2007. That means more opportunities for vendors, consultants, and competitors to attempt to spread FUD and sell you on their product. Don’t fall for these myths and be fooled into paying for something you already get with Exchange and DPM.

What myths have you heard? I’d love to hear them and address them in later posts!

The more Steph and I listen to Brad Paisley, the more impressed we are. (Those of you who don’t know who he is, he’s a country singer. If you don’t like country, that’s fine, you can stop reading, although I suggest you go to the video section of his website and at the very least watch Whiskey Lullaby, the duet he does with the incomparable Alison Krauss.) Tonight, though, I came in the middle of a new song on our local radio station: Letter to Me. The basic premise is simple: the song is a list of the things the singer would tell his 17 year-old self.

The best line of the song comes in the bridge:

And I’d end up saying have no fear
These are nowhere near the best years of your life

I don’t think I can tell you just how nice it is to hear one of these types of songs that doesn’t wallow in that sugar-coated all-American myth that “your high school years are the best years of your life.” Those years aren’t your best years — they shouldn’t be, at any rate — and if they are, you either need to pull your head out of your ass and look around to see how good your life is or you need to get in line for a serious kick in the ass.

Thanks, Brad. You continue to confirm that you are one of the coolest people in the music business.

I’m on my way out the door to fly to Chicago to present the last session of a Unified Communications show, but I want to give you a couple of quick tidbits:

• I’d like to welcome former Exchange MVP and former Microsoftie Kevin Miller to the ranks of the 3Sharp bloggers. Kevin joined us over the summer and has just now started blogging.
• I’m proud to share that I was selected to write the “MVP Article of the Month” for the November edition of the Microsoft TechNet Security Newsletter: Top 5 Exchange Server 2007 Security Best Practices.

Enjoy, and I’ll chat with you all next week!

Vegas was great again, this year; the hotel was as lovely as ever, but the overlap with the Latin Grammys sure did some interesting things to the elevators. Mandalay Bay felt full this year! On the other hand, the beach remodel was excellent; the wave pool and the Lazy River pool were both hits with my family. As is my wont, I’m making my session slide decks available for download.

• EXC16: Advanced Exchange Protection using Data Protection Manager
  Backing up and restoring Exchange servers is an essential part of keeping your messaging infrastructure up and running, even when you’re running an advanced clustering configuration. Why should you consider using the new version of Microsoft System Center Data Protection Manager (“v2“) to protect your Exchange server clusters? Is it any harder than backing up standalone servers? This session covers protecting Exchange 2003 and 2007 servers clustered configurations, including the new Exchange 2007 replication options.

  I thought this session went pretty well; there was a Microsoft session on Tuesday morning that looked like it was going to cover the exact same material, but the overlap was both smaller and shallower than I expected. I got a lot of good questions from this session which I’ll be answering in the next couple of days; I really hope that I was able to convey my own excitement about DPM and how it will make a great partner for protecting Exchange.

• EXC17: Exchange Management Shell Annoyances
  The Exchange 2007 Management Shell makes full use of the exciting new Windows PowerShell technology. It’s a great command-line management experience, but it’s still not perfect. You may have already been tripped up by annoyances and complications in what seem to be obvious tasks or you may just want to know what dangers lurk beneath the surface. This session will show you some common pitfalls and problems and give you the knowledge to successfully navigate them.

  This session suffered from the inevitable technical glitches; my Exchange virtual environment died an hour or two before the session, so I ended up having to run it from a stock Windows PowerShell session. Luckily, I was able to cover most of the territory from there and even add a couple of things or two. Not having the Get-Help and cmdlet completion information for EMS, though, just sucked; my apologies.

• EXC18: Getting Run Over by Exchange 2007
  Common knowledge says that upgrading to Exchange 2007 isn’t nearly as hard as the upgrade from Exchange 5.5. That’s not to say that it doesn’t present its own set of challenges—and if you’re caught by them, it will still feel like getting run over by a truck. This session will present some of the common gotchas and how to avoid them. Be at the head of the upgrade parade, not caught in the wheels.

  Wow. This was a great session; standing room only and a lot of good feedback and questions. This is clearly a topic of concern to people — if you have any other upgrade gotchas, let me know!