Paul's Down-Home Page

I’ve been married for nearly 15 years. During that time, I have never taken a vacation wherein I didn’t do some kind of work. Sad but true! Actually, “sad” isn’t quite the right word; the freedom to work from the road has let me spend a lot more time traveling with my family than if I had a job that required physical presence in a defined location. However, I’m breaking the mold: for the next seven days, I’ll be cruising the Caribbean with no laptop, and thus no email. I will have my trusty Treo, but it only works in 3 of the places we’re going to, and I’m mostly taking it so we can call the kids to see how they’re doing. I’ve already turned in my columns for next week, along with some other stuff that needed doing, so I’m free as a bird until 2/13. See you then!

This is interesting: Computerworld’s running a story saying that IBM has promised to make good its years of benign neglect by shipping a Mac Notes client that has feature parity with Windows. As someone who had to suffer through writing applications for the Mac Notes clients back in the day, I say “it’s about time”. Now, Microsoft: how about improving SharePoint support for Mac OS X?

Forbes Magazine has an interesting, if short, interview with Exchange sensei Tony Redmond. For those of you just stepping out of the spaceship, Tony is an ex-DEC, ex-Compaq messaging specialist with an incredibly deep background on messaging in general and Exchange in particular; he’s also a VP and CTO of the services division at HP.

Ever want to know how to effectively use limited user accounts (LUA) to run on Windows XP? Me too. Fortunately, MS just released a white paper that details what LUA is (and isn’t) and how to implement it on XP desktops. This is very valuable guidance– try it yourself and you’ll see what I mean.

It’s not often that I can praise Toledo (which I live near) as a technology leader. However, in yesterday’s Blade, a story by Mark Reiter gives me something legit to praise: the local federal district court is using iPods to pass out evidence to defendants for review. I’ve got a call in to Jeff Helmick, who’s quoted in the story, to ask some follow-up questions; check back here for an update.

I’m cleaning out my office (that faint sound you hear is applause from my wife). I have 12 copies each of Secure Messaging with Exchange 2000 and Secure Messaging with Exchange Server 2003 to give away. If you want one, reply via email with your postal address (be sure to tell me which one you want) and I’ll ship it to you. First come, first served.

Update: all of the Exchange 2003 books are spoken for, but I still have a few Exchange 2000 books available.

A reader wrote to quiz me about my recent columns on 64-bit Exchange and the performance benefits it should offer. He asked:

In your last e-letter you mentioned the added performance boost putting Exchange on a 64-bit box. For those of us that connect our Exchange servers to an iSCSI SAN, would we not run into bottlenecks at the NIC (1Gb backbone, assuming we were not using a TOE card or maybe even if we do), before a 32-bit setup cut into performance?

I’ll trot out my all-purpose answer: “it depends.”

First, let’s assume that you have a Gigabit Ethernet connection to the iSCSI SAN, with an HBA that has a native x64 driver– no thunking required. That’s just a clarification, but in the end it doesn’t really matter. Why? Assuming that you have “enough” RAM (where the precise value of “enough” varies according to the user workload on your server), JET 12 is going to be able to cache a significantly larger portion of the EDB data than it can now, meaning that the amount of bandwidth between your server and the iSCSI cabinet becomes much less relevant from a perf standpoint. We already see a similar effect now; when SAN vendors are hunting for business, they often put lipstick on the bulldog by adding a very large cache to the controller. Of course, this only works until the disks hit 70% or so of capacity, then the cache detunes and performance drops like a rock. That’s a problem only because the SAN controller has no idea what the application is doing; it’s not a problem for Exchange in this case because ESE is in charge of the cache. Given “enough” RAM, the amount of bandwidth you use for a given set of user behaviors should decrease because you’ll be making fewer requests to the actual disk.

What about page size? My gut feel is that the page size change will be a wash; caching will reduce the total number of IOPS that have to go over the wire, but those pages that do go will be 8KB vice 4KB. I’m looking forward to seeing hard data to confirm or disprove this, though.

Why did I say “it depends”, then, if the performance news is so rosy? Because one of the key reasons people will be deploying Exchange 12 is to consolidate servers. Obviously if you take four or five Exchange 2003 servers and stuff their mailboxes onto an Exchange 12 server, the new server is going to require a significant amount of SAN bandwidth, and I suspect it’ll easily be possible to build configurations that would saturate a GigE HBA. So, don’t do that and you should be good to go!