The Electric Wand : Business, Outlook

Business continuity – it’s a people thing, not just a premises one

Ewan — Thu, 12 Feb 2009 11:44:00 GMT

I had a really interesting discussion with a customer last week, when we were musing over the effects that the snow had on UK businesses. It was another example – like the floods which have hit parts of the country over the last few years – of a threat to business continuity which it’s easy to overlook.

Most businesses have prepared some contingency for what IT should do when it all goes wrong – starting with individual equipment failure (using RAID disks, redundant power supplies & the like), to clustering of services and replication of data to be able to survive bigger losses, either temporarily (like a power cut) or for longer-term outages (like loss of connectivity to a datacentre, maybe even loss of the datacentre itself).

What the weather conditions taught us the other day was that the people are even more important than the premises – the customer said it was ironic, that all their systems were up and running well, it was just that nobody was there to consume them.

Warwick Ashford from Computer Weekly writes about how their publisher, Reed Business Information, has built remote access into their business continuity plans. Interestingly, most of the discussion focussed on how to use VPN technology to connect to the office.

Funny, really. With Outlook & Office Communicator not needing to use a VPN to securely connect back to my office, I spent most of the WFH-time connected, productive, but not using a VPN at all.

The business case for Exchange 2007 - part IV

Ewan — Mon, 24 Sep 2007 16:12:02 GMT

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.

Exchange mailbox quotas and a 'paradox of thrift'

Ewan — Tue, 10 Jul 2007 14:38:00 GMT

The study of economics throws up some fantastic names for concepts or economic models, some of which have become part of the standard lexicon, such as the Law of Diminishing Returns, or the concept of opportunity cost, which I've written about before.

Though it sounds like it might be something out of Doctor Who, The Paradox of Thrift is a Keynesian concept which basically says that, contrary to what might seem obvious, saving money (as in people putting money into savings accounts) might be bad for the economy (in essence, if people saved more and spent or invested less, it would reduce the amount of money in circulation and cause an economic system to deflate). There's a similar paradox to managing mailbox sizes in Exchange - from an IT perspective it seems like a good thing to reduce the total volume of mail on the server, since it costs less to manage all the disks and there's less to backup and restore.

Ask the end users, however, and it's probably a different story. I've lost count of how many times I've heard people grumble that they can't send email because their mailbox has filled up (especially if they've been away from the office). End users might argue they just don't have time to keep their mailbox size low through carefully ditching mail that they don't need to keep, and filing the stuff that they do.

I guess it's like another principle in economics - the idea that we have unlimited wants, but a limited set of resources with which to fulfil those wants & needs. The whole point of economics is to make best use of these limited resources to best satisfy the unlimited wants. Many people (with a few exceptions) would agree that they never have enough money - there'll always be other, more expensive ways to get rid of it.

It's important to have a sensible mailbox quota or the paradox of being too stingy may come back and bite you. Some organisations will take mail off their Exchange servers and drop it into a central archive, an approach which solves the problem somewhat but introduces an overhead of managing that archive (not to mention the cost of procurement). I'd argue that it's better to use Managed Folders facilities in Exchange to manage the data.

The true paradox of mailbox quota thrift kicks in if the users have to archive everything to PST files, then you've just got the problem of how to make sure that's backed up... especially since it's not supported to have them stored on a network drive (though that doesn't stop people from doing it... Personal folder files are unsupported over a LAN or over a WAN link). Even worse (from a backup perspective) is that Outlook opens all the PST files configured in its profile, for read/write. So what this means is that every one of the PST files in your Outlook profile gets its date/time stamp updated every time you run Outlook.

This of course means that if you're storing your PSTs on a network share (tsk, tsk), and that file share is being backed up every night (as many are), then your PSTs will be backed up every night, regardless of whether the job is incremental/differential or full. I've seen large customers (eg a 100,000+ user bank) who estimate that over 50% of the total data they back up, every day, is PST files. Since PSTs are used as archives by most people, by definition the contents don't change much, but that's irrelevant - the date/time stamp is still updated every times they're opened.

So as well as losing any benefit of single-instance storage by leaving the data in Exchange (or getting the users to delete it properly), you're consuming possibly massive amounts of disk space on file servers, and having to deal with huge amounts of data to be backed up every night, even if it doesn't change.

If you had an Exchange server with 1,000 users, and set the mailbox quota at 200Mb, you might end up with 75% quota usage and with 10% single instance ratio, you'd have about 135Gb of data on that server, which would be backed up in full every week, with incremental or differential backups every night in between (which will be a good bit smaller since not all that much data will change day to day).

If each of those users had 1Gb of PST files (not at all extraordinary - I currently have nearly 15Gb of PSTs loaded into Outlook! - even with a 2Gb quota on the mailbox, which is only 30% full), then you could be adding 1Tb of data to the file servers, hurting the LAN performance by having those PSTs locked open over the network, and being backed up every day... Give those users a 2Gb mailbox quota, and stop them from using PSTs altogether, and they'd be putting 1.2Tb worth of data onto Exchange, which might be more expensive to keep online than 1Tb+ of dumb filestore, but it's being backed up more appropriately and can be controlled much better.

So: don't be miserly with your users' mailbox quotas. Or be miserly, and stop them from using PSTs altogether (in Outlook 2003) or stop the PSTs from getting any bigger (in Outlook 2007).