Another installment in a series of posts outlining the case for going to Exchange 2007. Previous articles can be found here.
GOAL: Make flexible working easier
“Flexible Working” might mean different things to differing organisations – some might think of mobile staff who turn up at any office with a laptop, sit at any free desk and start working – others might imagine groups of workers who can work from home part- or even full-time. Whatever your definition is, there’s no doubt that the technology which can enable these scenarios has evolved in great strides in recent years.
RPC Over HTTP – magic technology, even if the name isn’t
The “Wave 2003” of Exchange Server 2003/Outlook 2003/Windows XP SP2/Windows Server 2003 brought to the fore a technology which wasn’t really new, but needed the coordination of server OS, server application, client OS and client applications to make it available: if you’ve been using or deploying RPC/HTTP, you’ll know exactly what it does and why it’s cool. If you haven’t deployed it, the name might mean nothing to you… in short, the way in which Outlook talks to Exchange Server when you’re on the internal network, can be wrapped up within a secure channel that is more friendly to firewalls – hence “tunneling” that protocol (RPC) inside a stream of data which your firewall can receive (HTTP, or more correctly, HTTPS).
What this means in practice is that your users can connect in to your environment using a widely-supported network mechanism (ie HTTPS), and without requiring a Virtual Private Network connection to be established in the first place. This manifests itself in the fact that as soon as a user’s PC finds a connection to the internet, Outlook will attempt to connect to your network using HTTPS, and if it succeeds, will become “online” with Exchange and (if they’re using the default “cached mode” of Outlook) will synchronise changes between Outlook and Exchange since the client was last online.
A sometimes overlooked benefit of using regular internet protocols to connect the client & servers together, is that the communication will be able to leave one protected network, traverse the unprotected internet within a secure channel, then enter a second protected network. This means that (for example) your users could be connected to a customer or partner’s own internal network, but be able to go through that network’s firewall to reach your Exchange server. If you required a VPN to be established to connect Outlook and Exchange, then it almost certainly won’t be possible to use a protected network as your starting point, since the owners of that network will not allow the outbound connections that VPN clients use, but will allow outbound connections on HTTPS.
Now, RPC/HTTP was part of Outlook and Exchange 2003, however it’s been improved in Exchange 2007 and is easier to get up and running. If you’re also using Outlook 2007, the client configuration is a whole lot simpler – even if it’s the first time a user has ever connected to Exchange, all they may need to know is their email address and password, and Outlook will be able to find the Exchange server and configure itself using whatever default you’ve set. The technology behind the ease of configuration is called the Autodiscover Service, and the whole area of “connecting over the internet” functionality has also been given a more descriptive (to the non-techies, anyway) term: Outlook Anywhere.
From an end-user point of view, this technology is almost silent – for remote laptop users working at home, they often just start up their laptop, which connects automatically to a home wireless network and out to the internet, then Outlook just goes straight to Exchange and they’re online. Deploying this technology in Microsoft saw the volume of VPN traffic reduce dramatically, and the calls to the help desk concerning remote access dropped significantly too.
NET: Using Outlook 2007 and Exchange 2007 together simplifies the provision of remote access to remote users, particularly when using Outlook in “cached mode”. This configuration reduces, or even removes, the need to provide Virtual Private Network access, which could make the user experience better and save management overhead and expense.
Web client access instead of Outlook
Another element of flexible or remote working might be to use the web to get to email – maybe your remote users just want to quickly check email or calendar on their home PC, rather than using a laptop. Maybe there are workers who want to keep abreast of things when they’re on holiday, and have access to a kiosk or internet cafe type PC. Or perhaps your users are in their normal place of work, but don’t use email much, or don’t log-in to their own PC?
Outlook Web Access has been around for a number of versions of Exchange, and just gets better with every release. The 2007 version has added large areas of functionality (like support for the Unified Messaging functionality in Exchange, or huge improvements in handling the address book), meaning that for a good number of users, it’s as functional as they’d need Outlook to be. It’s increasingly feasible to have users accessing OWA as their primary means of getting to Exchange. One possible side benefit here is a licensing one – although you’d still be required to buy an Exchange Client Access License (which gives the user or the device the rights to connect to the server), you won’t need to buy Outlook or the Microsoft Office suite.
Outlook Web Access not only gives the web-user the ability to use email, calendar etc, but it can also provide access to internal file shares and/or Sharepoint document libraries – where the Exchange server will fetch data from internal sources, and display to the reader within their browser. It can also take Office documents and render them in HTML – so reading a spreadsheet or document could be done on a PC with no copy of Office available, or simply can be read without needing to download a copy of that document for rendering client-side in an application.
It’s possible to control what happens to attachments within OWA – some organisations don’t want people to be able to download attached files, in case they leave copies of them on public PCs like internet cafes – how many users would just save the document to the desktop, and maybe forget to delete it? Using server-side rendering of documents, all traces of the document will be removed when the user logs out or has their connection timed out.
Even for predominantly office-based users, OWA can provide a good way of getting to mail from some other PC, without needing to configure anything or log in to the machine – in that respect, it’s just like Hotmail, where you go to a machine and enter your username and password to access the mail, rather than having to log in to the whole PC as a given users.
If you deploy Outlook Anywhere (aka RPC/HTTP), you’ll already have all the infrastructure you need to enable Outlook Web Access – it uses the same Exchange Client Access server role (in fact, in Microsoft’s own deployment, “Outlook Anywhere” accounts for about 3/4 of all the remote traffic, with the rest being made up of OWA and Exchange Activesync).
NET: Outlook Web Access gives a very functionally-rich yet easy to use means of getting to data held on Exchange and possibly elsewhere on the internal network, in a secure means of communications to an external web browser. OWA 2007 has replicated more of Outlook’s functionality (such as great improvements to accessing address books), such that users familiar with Outlook will need little or no training, and users who don’t have Outlook may be able to rely on OWA as their primary means of accessing mail.
Mobile mail with ActiveSync
Exchange 2003 SP2 and an update to Windows Mobile 5 introduced the first out of the box “push mail” capability for Exchange, which forms part of the Microsoft Exchange Activesync protocol that’s also licensed to a number of other mobile device vendors. This allows Exchange to use the same infrastructure that’s already in place for Web access and for Outlook Anywhere, to push mail to mobile devices and to synchronise other content with them (like calendar updates or contact information). The Exchange Activesync capability in Exchange 2007 has been enhanced further, along with parallel improvements in the new Windows Mobile 6 client software for mobile devices.
Now it’s possible to flag messages for follow-up, read email in HTML format, set Out of Office status, and a whole ton of other functional enhancements which build on the same infrastructure described above. There’s no subscription to an external service required, and no additional servers or other software – reducing the cost of acquisition, deployment, and (potentially) in TCO. Analyst firm Wipro published some research, updated in June 2007, looking into TCO for mobile device platforms in which they conclude that Windows Mobile 5 and Exchange Activesync would be 20-28% lower in cost (over 3 years) than an equivalent Blackberry infrastructure.
NET: Continuing improvements in Exchange 2007 and Windows Mobile 6 will further enhance the user experience of mobile access to mail, calendar, contacts & tasks. Overall costs of ownership may be significantly lower than alternative mobile infrastructures, especially since the Microsoft server requirements may already be in place to service Outlook Anywhere and Outlook Web Access.
A last word on security
Of course, if you’re going to publish an Exchange server – which sits on your internal network, and has access to your internal Active Directory – to the outside world, you’ll need to make sure you take account of good security practice. You probably don’t want inbound connections from what are (at the outset) anonymous clients, coming through your firewall and connecting to Exchange – for one, they’ll have gone through the firewall within an encrypted SSL session (the S part of HTTPS) and since you don’t yet know who the end user is, an outsider could be using that connection as a way of mounting a denial of service attack or similar.
Microsoft’s ISA Server is a certified firewall which can be an end-point for the inbound SSL session (so it decrypts that connection), can challenge the client to authenticate and can inspect that what is going on in that session is a legitimate protocol (and not an attacker trying to flood your server with traffic). The “client” could be a PC running Outlook, a mobile device using Activesync or a web browser trying to access Outlook Web Access. See this whitepaper for more information on publishing Exchange 2007 onto the internet using ISA.
