Microsoft Brings Exchange into the Cloud

Microsoft on July 8 unveiled pricing information for its new Online Services initiative, in which the software titan wraps Microsoft-hosted Exchange and SharePoint services into a few aggressively priced subscription-based offerings.

While almost every organization relies upon e-mail (and, to a lesser extent, collaboration services), there are very few organizations for which e-mail server management expertise adds to the bottom line. Since any service that falls outside the core of one's business that can be consumed effectively as a utility arguably should be (and eventually will be), this move by Microsoft is a smart one.

The question, then, is whether Microsoft's new initiative will prove effective enough to coax consumers of on-premises e-mail into the hosted realm. Based on my initial tests of Microsoft's hosted Exchange service, I believe that Microsoft has a winner on its hands—provided that the firm irons out the service's beta kinks, and, just as importantly, manages to fight off the temptation to tie its online services more tightly to its bread-and-butter fat Windows client model than is necessary.

I kicked off my initial tests of Microsoft's hosted Exchange by signing on to the service's Web management interface, which, annoyingly, involved adding an exception in my Web browser to ignore the site's invalid SSL (Secure Sockets Layer) certificate. I then associated two domains with the service by creating DNS (Domain Name System) entries for each domain to verify my ownership and to route incoming mail to the Microsoft service.

Resource Library:

The DNS setup part of the process ran pretty smoothly, and had more to do with the control panel tools of my DNS providers (one through Godaddy.com, and one through 1&1 Internet) than with Microsoft's online tools per se.

Next, I created a few users through Microsoft's Web-based management console, and had the option of sending log-on details to an existing e-mail address of each of those users. With those steps complete, I turned to log in to the OWA (Outlook Web Access) interface of one of my new accounts, but found that before a user can log on to a hosted exchange mailbox, whether through OWA or not, he or she must first log on to the system through a local Windows application.

It's not clear how Microsoft expects users of its "light" OWA-only deskless worker version of the hosted services to handle this setup step. Perhaps the idea is that companies that choose the Web-only plan will maintain some kiosk machines to enable users to conduct their initial log-in chores before moving ahead with OWA.

The setup instructions on the management console directed me to put the setup file for the log-in application onto a file share. I would have preferred a download link from Microsoft's Web site, since chores like setting up file shares and managing installation of local applications are exactly what organizations that choose Microsoft Online Services are out to avoid.

Microsoft's log-in application runs only on Windows, naturally, and requires Version 3 of the firm's .NET Framework. For Windows XP users, this means another download and installation operation.

The log-in application is meant to provide for single sign-on for Microsoft's hosted services, and to handle initial setup of a local instance of Outlook, if there's one present on the client system. The application's Outlook setup function worked well enough, but when I fired up Internet Explorer, I was prompted for my password anyhow.

To be fair, my test Windows machine was running the beta of Internet Explorer 8, and this might have been at the root of the incompatibility I experienced. However, I also tested with Firefox 3 on Windows, and the single sign-on did not work there either, nor would OWA allow me to save my password in the browser.

As I learned while using the software on my Linux desktop (no log-in app available), Microsoft's online services OWA implementation comes with a relatively short time-out period. I didn't time how long it was before the software logged me out, but nearly every time I clicked back over to my OWA tab, I was asked to log in again. So far, I've found no option to lengthen the time-out period.

I expect that MS will straighten out this log-in app issue before the services come out of beta, but I hope that Microsoft manages to serve organizations that wish to travel a Web-only route, with local software as an optional, helpful component, just as fully as those that wish to keep a fat Windows client at the center of the implementation.

For now, it seems to me that Microsoft's local app requirement is a somewhat kludgey expression of the firm's "software plus services" mantra: Come for the services, but you're not getting away without some software, and, by the way, that software only runs on Windows.

For organizations interested in unlocking the benefits of SAAS (software as a service)—particularly those running non-Windows platforms—services plus software would be a much more attractive formulation of that slogan.