Exchange & Outlook

The iPhone 3GS and Exchange

Thu, 25 Jun 2009 09:00:06 MST

Many people think of marketing as a dirty word, a synonym for words such as lying, tricking, or overpromising. However, when done properly—and ethically—marketing can be pretty amazing. Consider what Apple has accomplished with the iPhone.

A little over two years ago, there was no such thing as the iPhone, but now it would be hard to find anyone in the industrialized world who hasn't seen or heard of it. Even my local paper, the famously stodgy Toledo Blade, ran a front-page story about the iPhone 3G release last summer. That level of familiarity and popularity is all due to a brilliantly conceived and executed marketing campaign, not to mention a product that appeals to consumers of all stripes.

I reviewed the iPhone 3G with iPhone OS 2.0 software, which was the first version to include Microsoft Exchange ActiveSync (EAS) support, and found that, as a mail device, the iPhone didn't stack up well against Windows Mobile. Now that Apple has released version 3.0 of the software along with the iPhone 3GS, it's time to take a look at its changes and see whether Apple has been able to move the needle.

Let's start with calendaring, which was one of the weakest parts of the 2.0 release. Apple has made some notable improvements here. The biggest change is that users can now invite people to meetings! This seems like a small step—and it is—but it removes one of the biggest limitations of the 2.0 software. For Exchange 2007 users, you can also view the attendee status of people you invite. When you receive a new invitation, you can use the Show in Calendar option to get a graphic view of where the appointment falls (see my blog for screenshots). However, there's no textual warning if the new meeting conflicts with an existing appointment. Also, you still can't see free/busy data for invitees or get suggested meeting times.

iPhone OS 3.0 has some notable improvements to email, too. You can choose individual folders to automatically sync (provided that you've turned push mail on), although the iPhone still insists on expanding every folder in your mailbox when you use the folder picker. iPhone OS 3.0 supports the use of client certificate authentication for Exchange access, and it adds support for some additional EAS password policy controls—as well as the EAS policy for controlling whether people can use the built-in camera.

Overall, though, even with these improvements, the iPhone still lags behind Windows Mobile 6.1 and 6.0 because it lacks some of their key features:

task support, including over-the-air synchronization
an easy way to add a contact from the GAL to your personal contacts lists
the ability to flag and unflag messages, a necessity for triaging email on the road
the conversation view found in the Windows Mobile 6.5 version of Outlook Mobile (remember, it's back-portable to Windows Mobile 6.1 devices as well)
correct behavior for IMAP deletes (the iPhone still doesn't send the correct IMAP EXPUNGE command to remove deleted messages)

So, my bottom line: the 3.0 release makes progress, but it's still not as powerful or useful as an email device as Windows Mobile is.

Related Reading:

Exchange 2010: No 32-Bit for You

Thu, 11 Jun 2009 09:00:06 MST

It's 2009. 64-bit technology offers clear benefits for security and performance—so why is it taking so long for people to adopt it?

I've been around computers long enough to remember the shift from 8-bit CPUs such as the Zilog Z80 to 16-bit CPUs such as Intel's 80286, and then to 32-bit units such as the Motorola PowerPC. At each stage, people eagerly adopted the new CPUs because the benefits in performance and memory addressing capability were quite clear. Adoption hasn't been the same for the move to x64 hardware and x64 versions of Windows, though, even though the scalability and security benefits of x64-based computing are just as obvious. Exchange Server 2010 and Exchange Server 2007, for example, make great use of the additional address space potential by letting you have extremely large Extensible Storage Engine (ESE) caches, reducing disk I/O by a large margin.

One objection to "going 64" is that 64-bit computing makes economic sense only for some types of application servers. There's certainly some truth to that argument, but it runs up against a sizable roadblock: There won't be a 32-bit version of Exchange 2010, even for test use. See the Exchange Team blog post "Is there a 32-bit version of Exchange 2010?" for this announcement. Some users are raising objections that they still need 32-bit versions. Are these objections valid?

The answer varies according to which component of Exchange we're actually talking about—but those components are all built from the same code base! For example, there are certainly customers who need to perform Exchange administrative tasks from 32-bit workstations. In Exchange 2007 and earlier, they could install the admin tools on their workstations, but because there won't be a 32-bit version of these tools for Exchange 2010, that option's off the table. The good news is that there are offsetting compensations and workarounds:

Exchange 2010 fully supports remote Windows PowerShell so that you can securely log on to a remote machine and use PowerShell—and the Exchange Management Shell (EMS)—to administer it. You can even use this procedure between different Exchange organizations; for example, I can fire up PowerShell at work and use it to manage my home domain remotely. (Granted, if you're not a PowerShell geek, you might not find this an exciting capability!)
The new role-based access control (RBAC) features in Exchange 2010 provide extremely fine-grained control over what administrators can do. RBAC lets you control not just which EMS commands—and, thus, Exchange Management Console (EMC) features—users can use, but even which parameters or switches they can specify. This amount of control makes it much easier to match capabilities with roles.
Many of the administrative functions available in EMC are now present in the new web-based Exchange Control Panel (ECP), which can be run from any machine that can run OWA; that means that non-Windows machines now have a fair shake).
Using RDP to remotely log on to the server and work remains a completely viable solution.

One use case that I haven't found a good solution for is that of having a Help desk that uses EMC solely to perform user management and provisioning tasks. These tasks are accessible through remote PowerShell, but they're not available through the ECP. A web-based provisioning tool is probably the best solution for these users.

This discussion has so far avoided any mention of 32-bit versions of Exchange itself, such as the ones commonly used for building test or demo environments. Here, I'm sad to say, the writing is on the wall: If you want to work with Exchange 2010, you'll need a 64-bit-capable machine and a 64-bit OS to run it on. That might mean investing in new lab hardware, laptops, or other resources, but there's no way around it—once you go 64-bit, you'll never go back!

Related Reading:

Exchange 2007 Now or Exchange 2010 Later?

Thu, 28 May 2009 09:00:06 MST

I had a great time working in the Technical Learning Center (TLC) at the recent TechEd North America 2009 event in Los Angeles. It's always fun to talk to attendees and find out what they want to know about Exchange Server. Microsoft unveiled a lot of details about Exchange Server 2010 at the show, so it's natural that the TLC staff got more questions than usual about the new version.

The most common question I heard was entirely predictable: "If I'm on Exchange 2003, should I move to Exchange 2007 now or wait for Exchange 2010?" I heard this question asked, in different forms, by dozens of attendees representing all sizes of organization from all geographies. Unfortunately, there's not one simple answer; there are probably as many variations of answer as there are differences in Exchange deployment.

For example, one fellow I spoke to said that he still had one Exchange 5.5 server in his environment, along with a dozen or so Exchange 2003 servers—and a few Windows NT 4.0 domains! He estimated that it would take about a year for him to have everything moved over to either a Windows Server 2008 or Windows Server 2003 native-mode forest, and to expunge the old Exchange 5.5 server and all its mailbox data. In his case, the answer is simple: wait and move directly to Exchange 2010. Based on his description of the environment, there's not much point in expending resources to deploy Exchange 2007 later this year when the underlying directory infrastructure is in such a mess.

However, a more common situation is that of the numerous organizations who are poised to move to Exchange 2007 from Exchange 2003. Perhaps they want to take advantage of the much reduced I/O load—and corresponding increase in scalability—of Exchange 2007. Or maybe there are particular features, such as unified messaging, that are driving their upgrade requirements. For these organizations, the answer isn't quite so clear-cut.

Let's start with the presumption that most companies won't want to spend time, effort, and money on a double upgrade—first to Exchange 2007, then later to Exchange 2010. Many people I spoke with told me flat out that they could afford to upgrade once, but not twice. For those folks, their question was really better expressed as, "Is Exchange 2010 worth waiting for?" When phrased that way, I think the answer is a strong yes. Why?

For companies that are seeking relief from Exchange 2003's I/O characteristics, Exchange 2010 offers further improvement—as much as 50 percent by some estimates—over Exchange 2007's already-impressive gains.
The Exchange high availability story gets both simpler and more flexible with the introduction of database availability groups, thus easing another pain point for Exchange 2003 shops that want to move away from shared-storage clustering.
Every feature area in Exchange 2010 offers significant functionality improvements over Exchange 2007—from unified messaging's new Voice Mail Preview feature to the dramatically better OWA experience, these changes offer major benefits to system administrators and end users.

For the lucky few that can afford the luxury of doing two upgrades, or the unlucky few who have such unstable environments that they need to upgrade right away, it might still make sense to move to Exchange 2007 now, especially given that doing so will accomplish most of the heavy lifting of an Exchange 2003–to–Exchange 2010 upgrade.

However, I don't expect to see many companies fall into either of these categories. Anecdotal evidence so far tells me the opposite—but I'm willing to be proven wrong. We've cooked up a poll below to gather more explicit data to show what Exchange 2003 shops are planning on doing. You can also drop me a line to let me know what your migration plans are.

For organizations currently using primarily Exchange Server 2003, what are your upgrade plans?(web polls)

Related Reading:

TechEd 2009 Sessions for Exchange Admins

Thu, 07 May 2009 09:00:06 MST

Next week, Microsoft is throwing its big annual technology bash for North America, TechEd 2009, in Los Angeles. Last year, TechEd was split into two separate events: one for developers and one for IT professionals. This year, the two are combined again. Usually, I'd complain about the combination because I think it reduces the number of available sessions for the technologies I'm interested in, but this year there are plenty of sessions focusing on unified communications, security, and other top-of-mind topics.

The big news for us Exchange Server administrators, of course, is that TechEd 2009 is the big coming-out party for Microsoft Exchange Server 2010. Microsoft has been steadily releasing details on Exchange 2010 since earlier this year, including the release of the public beta on April 15. However, as B. K. Winstead pointed out in his article "Exchange 2010: Problems, Problems, Problems," there are still several unanswered questions and problems around the public beta release. There are also some things that Microsoft has not yet talked about in its public disclosures.

Based on the session agenda available on the TechEd website, here are a few sessions that should be of particular interest:

"Introduction to Microsoft Exchange Server 2010" (UNC204)—This session is a keynote by Michael Atalla and Rajesh Jha from Microsoft. Expect this session to focus on the integration between on-premise Exchange and the Exchange Online service, as well as showcasing some of the new client access features. If we're lucky, the Office team will let Outlook 2010 out of its cage for this session, too, so we can see how it works with Exchange 2010.
"Microsoft Exchange Server 2007 SP1 and Microsoft Hyper-V: Dos and Don'ts" (UNC308)—In the past, the Exchange virtualization story was all about the "don't" aspect. With this session's intriguing title, it will be interesting to see what supportability changes Microsoft has in mind for the newest version.
"High Availability in Microsoft Exchange Server 2010" (UNC313)—This session will cover the new database availability group (DAG) architecture in depth. This should be popular with people who are wondering what the excitement is all about and whether DAGs are a suitable replacement for their existing high-availability solutions.
"Microsoft Exchange Server Outlook Web Access 2010: The Future of Web-Based E-mail" (UNC320)—If you haven't seen OWA 2010, you're in for some very pleasant surprises, and you should definitely hit this session to see it in action.
"Microsoft Exchange Server 2007 High Availability and Disaster Recovery Deep Dive" (UNC402)—This is the only 400-level session related to Exchange I expect this session to have some lively discussion about the best way to plan a high-availability architecture with Exchange 2007 while preparing that architecture for an eventual move to Exchange 2010.

Last, but hopefully not least, I'm presenting two sessions. "Deploying, Administering, and Managing Microsoft Office Communications Server 2007 R2" (UC304) is on Wednesday, May 13, at 1:00 P.M. I'm also presenting "Managing Messaging and Collaboration in the Cloud with Microsoft Online Services" (UNC01-INT), an Interactive Theater session on the Exchange Online service. If you're at TechEd, come by and say hello!

Related Reading:

Exchange Server 2010 Beta Tips

Thu, 23 Apr 2009 09:00:06 MST

On April 15, Microsoft released a public beta of Exchange Server 2010, formerly code-named Exchange 14. I've had the opportunity to spend a lot of time working with the new version of Exchange since before the public beta, and I thought I'd share a few tips and tricks that might be useful to you.

First of all, don't even think of installing the beta in production. It's not supported or licensed for production use, and there's no guarantee that you'll be able to upgrade from this beta to later betas (if any) or to the release version. Nino Bilic on the Exchange team blog also has something to say about this point.

Second, keep in mind the prerequisites you'll need to download and install before you install the Exchange 2010 beta. I had hoped that Exchange 2010 would automate installation (or at least downloading) of the prerequisite updates it requires, but it doesn't. Microsoft's Scott Schnoll posted a step-by-step installation guide on his blog that you can use as a guide. There are two sets of prerequisites: Windows features that you must have installed, such as the Windows RPC over HTTP proxy server for the Client Access server role; and patches or updates to existing features, including Microsoft .NET Framework 3.5 and the latest version of the Windows Remote Management (WinRM) management service.

Third: Exchange 2010 requires PowerShell 2.0, which supports remote management. When you use the Exchange Management Shell link on the Windows Start menu, you're actually getting a remote PowerShell session on the same machine. In some cases, remote PowerShell sessions don't start properly. If that happens, look in the Start menu again and you'll see an Exchange Management Shell (Local PowerShell) link. Use it instead, and you'll be in good shape.

Finally, remember that there are some features that Microsoft has shown or talked about that aren't included in the public beta build. It's not always obvious what these features are, and it's easy to mistake a missing feature for one that isn't working right. The public beta build doesn't support integration with Microsoft Office Communications Server 2007 R2, for instance. MailTips are implemented on the server side, but on the client you need either Microsoft Office Outlook 2010—which isn't available yet, even in beta—or a newer build of OWA 2010 than the one included in the Exchange 2010 beta. If you're not using one of those two clients, you won't see MailTips displayed even if you've defined them on the server.

There's a lot more to say about the beta, and I'll be continuing to cover it in future columns. If you have questions you'd like to see answered, drop me a line at probichaux@windowsitpro.com.