Exchange & Outlook

Exchange 2007 Will Run on Server 2008 R2 . . . Eventually

Thu, 12 Nov 2009 04:01:07 MST

My September 24 column was all about running Microsoft Exchange Server 2007 on Windows Server 2008 R2. Quick summary: Microsoft said "we won't support it," and I spent a whole column explaining why that seemed like a sensible idea. (See "Exchange 2007 and Windows Server 2008 R2.")

Last week, Microsoft made that column obsolete with a new announcement: They are going to support Exchange 2007 on Server 2008 R2 after all. The announcement, by Kevin Allison, the general manager of the Exchange Customer Experience team, was pretty vague, promising that "in the coming calendar year we will issue an update for Exchange 2007 enabling full support of Windows Server 2008 R2." That leaves a number of questions open, such as exactly what form this update will take (Service Pack 3? A really large update rollup?) and when it will ship.

I still think the reasoning in my previous article is sound. First, Microsoft hasn't been supporting upgrades to the OS of an Exchange server after Exchange is installed on it, and it seems unlikely that they'll suddenly start. That situation means that the utility of Server 2008 R2 support will initially be limited to those customers who are willing to do clean installs of R2, followed by reinstallation of Exchange on the upgraded machines. If you have to do installs of both the OS and Exchange, you might as well move straight to Exchange 2010 (except that you might, depending on your licensing plan, have to buy Exchange 2010 separately).

Second, the list of reasons to upgrade to Server 2008 R2 still doesn't strike me as super-compelling for Exchange. There are definitely some good reasons to upgrade domain controllers and global catalogs, remote access servers, and other roles, but the benefit for Exchange is smaller.

So, if I'm right (and even if I'm not), why did Microsoft reverse its stance? Simple: Customers demanded it—loudly. This reversal is a great example of how customer feedback, communicated through a variety of channels—including Microsoft's field sales and technical support force, but also through blogs, forums, and other Internet-based feedback mechanisms—can cause even a very large company such as Microsoft to change its stance on something. I take it as a positive sign that the Exchange team is listening to us and taking our requirements into account, and I hope that this trend continues.

Mobility News from Microsoft, Verizon, Adobe

Thu, 15 Oct 2009 04:01:07 MST

Last week saw the emergence of several major news items in the mobility world, all of which have something to do with Microsoft Exchange Server. Of course, it's no coincidence that these things happened during the same week, but the overlap is pretty interesting.

First, Microsoft delivered on its promised release date for Windows Mobile 6.5, along with the launch of its new "Windows phone" branding campaign. Because of the way that Windows Mobile is built and released, Microsoft actually shipped the bits to OEMs about six months ago. The OEMs, such as HTC, integrated their device-specific drivers and extensions, then the mobile operators (e.g., AT&T, Verizon, T-Mobile) added their customizations and extensions. That process gives the OEMs and mobile operators great flexibility, but it also raises one of the biggest complaints about Windows Mobile: Mobile operators have shown a great degree of ingenuity and capability when it comes to taking a perfectly functional Windows Mobile build and crapping it up with all sorts of add-on icons, programs, and general junk.

From an Exchange perspective, the big news in Windows Mobile 6.5 is its dramatically improved version of Outlook Mobile. Sporting an Outlook 2010–like conversation view, SMS syncing with your primary mailbox, an inline player for voicemail, and a ton of other features, Outlook Mobile is one of the best things about Windows Mobile 6.5, especially because it can be upgraded over the air. In fact, Windows Mobile 6.1 devices can get in on the fun, too, using Exchange 2010's ability to provide a bootstrap loader that the mobile device can use to download and run the correct version of the Outlook Mobile 6.5 installer.

For the second piece of news, Verizon (which launched a Windows Mobile 6.5 device last week) announced that it was planning on releasing new devices based on Google's Android OS. This news is interesting for a couple of reasons. One reason is that the base Android OS doesn't include Exchange ActiveSync (EAS) support, although HTC includes EAS support in some of its Android phones (and although there are several third-party Android EAS clients available). Verizon is now in the enviable position of supporting three families of Exchange-capable devices: BlackBerry, Android, and Windows Mobile. That doesn't seem to leave much room for the rumored Verizon version of the iPhone. Separately, Verizon introduced a new campaign criticizing AT&T's well-known 3G network problems; it'll be fun to see how that plays out in the coming months.

The third mobile news item last week came from Adobe, who announced that it's going to deliver Flash runtime capability for Windows Mobile, Android, Palm webOS, and BlackBerry devices. Apart from opening up the floodgates for poorly written Flash-based games, this development introduces the possibility that we'll see social media applications—such as the very popular TweetDeck app, which is built on Adobe's AIR technology—that take greater advantage of the wealth of data stored in Exchange databases via mobile devices. (Personally, I sure would like to see a mobile-device equivalent of the managed version of the Exchange Web Services library.)

As a final note, Motorola vice president Christy Wyatt was quoted in the press as saying, in reference to the number of mobile operating systems, "We just don't believe long term it's going to be sustainable . . . you'll see the number go from 10, down to 8, down to 5, down to hopefully 2 or 3." We'll see if she's right.

Exchange 2010 Released to Manufacturing

Thu, 08 Oct 2009 04:01:07 MST

Microsoft today announced the release to manufacturing (RTM) of Exchange Server 2010 with a post on the Microsoft Exchange Team Blog. This is great news, especially for those who have been waiting for its release to move from Exchange 2003. The formal launch will take place in early November at TechEd Europe in Berlin.

Microsoft has been talking about Exchange 2010 for quite some time, and I figure that by now most UPDATE readers already have a good idea what to expect from its new features. I wanted to talk a little bit about the release process itself, though.

As you might know, Microsoft's been using Exchange 2010 to host almost 10 million mailboxes through its Live@edu and Exchange Labs programs. This is a huge departure for Exchange, which historically has been tested before release on a few hundred thousand mailboxes at most. One of the explicit design goals for Exchange 2010 was to have the same code scale and run well for both hosted and on-premises use. Large-scale testing was necessary to validate that the goal had been met.

Of course, Microsoft's own operations weren't the only ones using Exchange 2010 during its development. Members of the Technology Adoption Program (TAP) ran it, too, with more than 100,000 mailboxes of their own in production use from fairly early on. TAP members get access to interim builds and technical support from the Microsoft Customer Service and Support (CSS) engineers who are in the beta support rotation. In exchange, the TAPs have to wring out the product thoroughly and suffer through the occasional problems and failures that inevitably happen during the development cycle.

Microsoft has TAPs for other programs, too, but the Exchange TAP is exceptional in several ways. For instance, based on their personal experience with the product, TAP members vote on whether it's ready to be released. If there are major bugs that prevent TAPs from using the product in production, they can blow the whistle and delay the RTM until things are fixed. The Exchange developers made builds of Exchange 2010 available to TAP members on a regular, and frequent, schedule so that changes and bug fixes could be evaluated sooner rather than later.

The most remarkable thing about the Exchange TAP program, though, is the extraordinary degree of engagement and support that the product team provides to TAP members. The project managers, developers, testers, and management on the Exchange team actively asked for feedback, paid careful attention to it, and often stepped in to help solve thorny problems that the TAP members faced—even when, as in a couple of my own situations, they were self-inflicted!

I don't know what the official street date for Exchange 2010 is, but a reminder: Volume license customers will be able to download it before the retail kits are built and shipped, so I'd expect that to be within the next month.

I'm curious to know whether your plans to deploy Exchange 2010 have changed based on what you've learned since TechEd North America this summer. Drop me a line and let me know your thoughts.

Exchange 2007 and Windows Server 2008 R2

Thu, 24 Sep 2009 04:01:07 MST

Microsoft recently announced that Exchange Server 2007 wouldn't be supported on Windows Server 2008 R2. This decision has generated a bit of controversy, with Exchange administrators asking why a still-current product isn't being supported on a brand-new OS. In an attempt to clarify its reasoning, the Exchange product team posted an explanation on the Microsoft Exchange Team Blog that boiled down to two points:

Exchange 2007 SP2 was in development before the Server 2008 R2 release cycle, so SP2 would have been "delayed significantly" if it had to be tested against R2
Microsoft doesn't support upgrading the OS of an existing Exchange installation, and they don't plan to change this stance. They say that customer feedback indicates that the big need relative to Server 2008 R2 is to support R2 domain controllers, which Exchange 2007 SP2 does.

These points seem reasonable. After all, the product group is nearly done with a huge revision to Exchange in the form of Exchange Server 2010. Diverting testing and engineering resources to make sure that Exchange 2007 runs on a not-yet-released OS (remember, R2's street date is October 22) that you can't upgrade to in-place anyway doesn't make much sense.

However, I think there's another reason it makes sense not to support R2 with Exchange 2007: What would we actually gain?

Take a look at Microsoft's list of the top 10 reasons to upgrade to Server 2008 R2 and you'll see what I mean. Reduced desktop costs? Ubiquitous remote access? Although these features are no doubt useful (and some, like DirectAccess, are technically sweet as well), they have nothing to do with Exchange. Improvements to R2's Hyper-V implementation would benefit Exchange deployments, but to take advantage of them you'd have to be running your Exchange organization in a VM anyway, not directly on the host OS, so that point is moot too.

This isn't to say that R2 doesn't have other interesting reasons for a potential upgrade. For example, the Active Directory (AD) Recycle Bin is a neat concept that I think could be very useful in large-scale Exchange deployments, and the aforementioned DirectAccess (along with the new BranchCache system) is a terrific enhancement for distributed networks. However, there's just not much in R2 that directly benefits Exchange 2010, much less Exchange 2007, so I think the decision to put engineering resources into new development, rather than sustaining engineering support for running Exchange 2007 SP2 on R2, is further validated.

Having said that, it will be really interesting to see what the prevalent combination of OSs and Exchange versions will be a year from now. There's clearly a strong wave of pent-up demand for Exchange 2010 from companies that are on Exchange 2003 and are skipping Exchange 2007 altogether, but how will that translate into OS deployments? We'll have to wait to find out, but I'm betting that Server 2008 isn't ready to ride off into the sunset just yet.

Load Testing with Exchange 2010

Thu, 10 Sep 2009 04:01:07 MST

Load testing has been part of the Microsoft Exchange Server landscape for a long time. The MAPI Messaging Benchmark (MMB) suite of tests was designed to provide a way to measure the performance of a given set of hardware; see this 9-year-old Exchange UPDATE article for more details. The problem with benchmarks, of course, is that they provide an almost endless number of ways to get things wrong.

There are two ways to resolve this problem. One way is to have an ever-more regimented set of benchmark procedures, which is the approach taken in the database world with the Transaction Processing Performance Council (TPC) series of benchmarks. The other way is to move away from benchmarking—which tries to answer the question, "Who's the fastest?"—and do load testing instead, which tries to answer the question, "Is this hardware fast enough?" For Exchange Server, Microsoft has adopted the latter approach.

You might remember that when Exchange 2007 launched, Microsoft made some fairly strong claims about the improvement in I/O performance compared to Exchange 2003. In fact, I/O reduction was one of the major design elements of both Exchange 2007 and Exchange 2010. Reducing the number of disk I/O operations required to service a given workload means that you can get by with smaller numbers of disk spindles, which means that many workloads no longer need SANs because they can efficiently use large-capacity SATA disks instead of faster, smaller, more expensive SAN disks. (Stay tuned to Windows IT Pro for more in-depth articles on the storage and database layout changes in Exchange 2010.)

However, you'd have to be very, very trusting to take Microsoft's word about the impact of these changes. There are so many variables that can influence Exchange disk performance that the only way to be sure is to test Exchange on the hardware you plan to use (or a reasonable facsimile) and see how it performs. That's what the Exchange Load Generator (Loadgen) toolset is for; it was originally released in January 2007 and has been periodically updated. The newest update was released last week. It's a superset of the Exchange 2007 version of Loadgen that adds support for Exchange 2010 in a number of ways:

It properly generates load for Exchange 2010's all-new OWA implementation.
It can dynamically generate mail content according to a profile you specify so that you get on-demand messages instead of having to use a canned set.
It incorporates support for Exchange ActiveSync (EAS). I haven't tested this feature yet, but I'm eager to because scaling Client Access servers for EAS devices is still very much a black art that requires a lot of guesswork and overprovisioning.

At the same time, Microsoft also released a new version of Jetstress, the I/O load tester that lets you validate whether your storage subsystem design can deliver enough I/O operations per second (IOPS) to meet a given Exchange load. The big news here is that the new version implements the Exchange 2010 database I/O profile, including the change to a 32Kb page size. It also imitates the behavior of Exchange 2010's log replication toolset.

Running these tools doesn't guarantee that you won't have performance-related problems, but it certainly does make it less likely!