The Electric Wand : Outlook

Exchange in the cloud or on the ground?

Ewan — Wed, 18 Nov 2009 10:02:42 GMT

Following the price cut on the desperately-in-need-of-renaming BPOS services recently, I’ve been talking with a few people about the where the tipping point might be for running Exchange in house vs using some form of hosted provision.

There are plenty of reasons why a hosted offering makes sense. More and more end-users are away from the office (using web access, mobile devices or VPN-less connectivity such as “Outlook Anywhere” that’s been part of Outlook for the last 6 years), and as the user end-point is increasingly mobile, it starts to matter a lot less where the server end is.

In the first 3 versions of Exchange (4.0, 5.0 and 5.5, released in 1997 and 1998), the accepted rule was that servers would be placed in the same location as clumps of users (say, if you have more than 30 users in a remote office and anything other than a great WAN connection, you’d drop an Exchange server on-site.

Since the client and server maintained a constant connection with each other (using MAPI over RPC, if you’re interested), and since wide area networks for most companies were in the few hundred kilobits between sites, the default was pretty much that servers tended to be in the same physical location as the users.

As network capacity improved (and costs fell), combined with server capability improvements (and price reductions, and technology like Outlook cached mode and the shift to using web access as an alternative, it became more feasible for organisations to centralise and consolidate Exchange into one or a few physical locations – such as Microsoft famously did, by moving from many locations in Exchange 2000 to just 3 in Exchange 2003.

So the position we’re now at is, it pretty much doesn’t matter to an end user whether they’re connecting over a company wide-area network to a remote Exchange server, or if they’re connecting over the internet to one that sits in someone else’s datacenter.

If you’re an organisation with few hundred users, then you probably don’t have a dedicated Exchange administrator who does nothing but feed and water the email system. Moving to an online hosted model such as Microsoft Online or one of the many “Hosted Exchange” partners who offer a more tailored service, could mean a significantly lower cost of operations when measured over the next few years.

Since Hosted Exchange providers and Microsoft Online will both move towards Exchange 2010 in the near future, it’s something that every current Exchange users should consider – is it time to consider moving some or all of your estate to a hosted environment, or you do have specific requirements around backup retention or data control, that you absolutely need to have your own servers on your own soil? If the latter, then maybe “cloud” based email isn’t for you, but Exchange 2010 “on-premise” would be the right choice.

Outlook 2010 beta and E.164 number format updater

Ewan — Tue, 06 Oct 2009 23:26:14 GMT

Well hello again; it’s been a while.
Normal service should now infrequently resume.

I thought I’d update the instructions of a previous post, after I was showing someone how to use my old “Contacts updater” application to make all their Outlook contact phone numbers be E.164 compliant.

(see blogs passim. eg here, here, or here.)

Now the little app I reference is an Outlook custom form, meaning it gets installed into the Exchange mailbox folder, rather than some client-side Add-in to Outlook. Custom Forms have been available since the days of the Exchange 4.0 client and later Outlook, as the installed forms show up an item on the “Action” menu within the view of the folder.

Now that Outlook 2010 has adopted the Fluent UI (aka the “Ribbon”), things have moved somewhat…

Just like the early days of Office 2007, the initial response from some users might be to get annoyed that things are in a different place, but in most cases, it’s a great improvement.

Since custom forms in Outlook have largely faded into the sunset, this particular one gets a bit more obscure… it’s a question of going to “New Items” within the folder, then selecting the “Custom Forms” pop-out (only available when you actually have some custom forms installed in that folder), and any forms installed will be presented there.

Office Web Apps complement, not replace, Office

Ewan — Tue, 04 Aug 2009 13:54:00 GMT

The Office 2010 announcement a couple of weeks ago, (publicly) lifted the lid on the Office Web Applications, either as a set of web-based Office apps that a customer could host on their own metal (and expose to the outside world, perhaps), or as something that you’d be able to get online from others. Microsoft’s own “Office Live” workspaces will use Office WebApps, for example.

It’s easy to think that moving to an online-based set of productivity applications would be an either/or decision – like today, you could choose to do either Office (as a client side set of apps) OR Google docs (as an online variant).

Maybe Office WebApps will blur that distinction a good bit. As an illustration, I was in an interesting talk last week, where the speaker asked:

Who in here uses Outlook Web Access?

(everyone’s hand goes up – well it was a Microsoft audience, so no surprises there)

OK, who now uses Outlook *less* because they also use OWA?

Literally, not a single hand went up.

So, for business use, you could think of Office WebApps as a way of interacting with the same documents, the same data, that you would if you were inside your company and using Office applications on a PC, but instead you’re at home or you’re at someone else’s machine, or maybe you just want to share your document with someone from outside the company. WebApps are promised with every version of Office, too, as is OneNote – finally making OneNote available to everyone, not just Professional or Student users.

More info on the Office Web Applications blog.

Office 2007 SP2 now available

Ewan — Tue, 28 Apr 2009 21:47:45 GMT

I’ve been beta testing Office 2007 SP2 since the beginning of the year, and it’s been great – the single biggest reason to use it is the myriad improvements made to Outlook, in terms of stability & performance (particularly relating to search and to startup & closedown).

Download Office 2007 SP2 here

From the summary of what’s new, check out:

Microsoft Office Outlook

Performance improvements that apply to the following general responsiveness areas:
- Startup
  Removes lengthy operations from initial startup.
- Shutdown
  Makes Outlook exit predictably despite pending activities.
- Folder View and Switch
  Improves view rendering and folder switching.
Calendar improvements
Improves underlying data structures and the general reliability of calendar updates.
Data file checks
Greatly reduces the number of scenarios in which you receive the following error message when you start Outlook:

The data file 'file name' was not closed properly. This file is being checked for problems.
Search reliability
Improves search reliability when you use SP2 with Windows Desktop Search 4
Improvements to Really Simple Syndication (RSS)
There are now fewer duplicated items.
Object Model improvements
Now contains many customer-driven fixes.

For more information about these improvements and details about other Outlook fixes, click the following article number to view the article in the Microsoft Knowledge Base:

968774 Outlook 2007 improvements in the 2007 Microsoft Office suite Service Pack 2

Outlook Thread Compressor download now available

Ewan — Sat, 11 Apr 2009 16:34:00 GMT

Nearly a year ago, I wrote about Thread Compressor on here – it’s an add-in to Outlook which removes unnecessary emails, on the assumption that most people reply to mail and leave the original intact, so you could keep the last mail in each branch of a thread, and remove all the others.

Way back when I was still developing TC, I tried to get it included on the Office Downloads section of Microsoft.com, but our legal department was (with some justification) very nervous about us offering a download which would go through the end user’s mailbox like a dose of salts, deleting stuff. So it stayed (more or less) an internal tool: I even started developing a “version 5” with a much groovier UI and some extra features.

Included in the v5 beta (which is a real pain to install nowadays – the previous v4.2.030 version has nearly the same feature set and is a lot more self contained), was a piece of logic which captured stats on TC usage and emailed them back to me.

Since many people at MS are still running that beta (it’s a long story, but the source code went south so it’ll never get out of “beta” state), I still get maybe 20-30 statistics mails a day…

Since August 2003 when the first statistics email arrived – from me, kind-of naturally – until 24th April 2007 (when I last did an analysis of the stats), TC v5 beta had scanned over 400m email messsages and had compressed over 30m, worth nearly half a terabyte of email data.

To the reader, the spoils

Well, I finally decided – in an “ask forgiveness rather than permission” move – to make the last complete and stable version available for download.

It’s not particularly elegant looking by modern standards (given that most of it was written 7 years ago in VB6) but it does work, even on Windows 7 (x86 and x64) and Office 2007. Basically, anything post-Office 2000/Windows 2000 should be OK.

A reader called Mark Ruggles emailed me the other day and said:

“It is fantastic and it works like a champ in Outlook 2007. I turned it loose on my Inbox and my archive and I deleted 103Mb of redundant data. I sent it out to some of my colleagues and my manager used it cutting his archives down by 2Gb.
…
This is the coolest utility I’ve found in a long time.”

So, thanks to Mark's comment, I’ve now registered www.threadcompressor.co.uk and posted install instructions and a download file up there.

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.

Border Lines in Word & Outlook

Ewan — Fri, 12 Dec 2008 11:10:00 GMT

OK, I've been bad. Let my blog -

which I used to update fairly frequently, though not the multi-posts-per-day, at-any-hour-of-the-day type thing that Steve Clayton does. Maybe that's why he wins awards and I don't :)

- wither and dry up. I got a new job about a year ago which means I'm now less hands-on with technology (ie. am now dispensable middle-management overhead), and that's certainly not helped.

Anyway, New Year's resolution is to try to keep it up to date a bit more, with tips & tricks, snippets of interesting news and maybe the odd essay on stuff that I think might be important.

Making lines in Word & Outlook

Today's tip is something I came across by accident and use all the time. Since modern versions of Outlook use Word under the covers as their editor, it applies all through the program. It's a way to create "Border Lines" quickly.

My favourite use for it is when you're updating a meeting in the calendar and you want to give the attendees a short explanation of why you're moving the time, changing the agenda etc. Best place to do that is right at the top of the body text, and a nice line between the original and what's new provides clear separation.

The tip is - if you type three dashes "---" and press Enter, the Word engine replaces the dashes with a horizonal line that spans the width of the document/appointment/email. Example:

Some wisdom

---

Some more wisdom

... hit enter at the dashes and it becomes

Tip for finding when an appointment was created

Ewan — Mon, 21 Apr 2008 15:52:35 GMT

Here's a tip for when you suspect someone has magicked up an appointment to coincidentally collide with an Outlook meeting request you sent them...

In your own calendar (and other people's), you can see when a meeting was scheduled (ie request was sent or created), as well as other facts (like when you accepted it) - eg:

If a blocked out time in the calendar is just an appointment (ie something that was just put there by the owner of the calendar), you don't see the date it was added...

Remember, they're all just forms in the end

Way back when Exchange was young (it started at 4.0), the design was that emails/meeting requests etc, were just an "item" (which is a collection of fields, different depending on the type of item it is), and a "form" which was associated with a particular kind of item using the Message Class to denote it.

In other words, an email message would have fields like Sender, date, recipients, subject, etc. And when you went to open a message, the Exchange client (later, Outlook) would look at the class on the item (IPM.Note, for a message) and would find the appropriate form to open that item. Clear? If you really want examples of lots of different Outlook items, see MSDN.

Anyway. If I'm looking at an appointment which wasn't a "meeting" (ie it was just put into my or someone else's calendar, not via a meeting request/acceptance), I might not be able to see the date it was created, but the underlying item definitely does have that property. Displaying it in Outlook is pretty straightforward, if a little contrived. Here's one quick & dirty method of doing so (I may post a more elegant solution if there's interest)...

1. Get to "Design this form"

Older versions of Outlook had a Developer item on the menu structure which allowed you to select (via several pop-outs if I recall) to design the current form. Outlook 2007 simplified the menus (now using the Ribbon) and no longer shows that Developer menu. One quick way of putting it back is to add that specific command to the "Quick Access Toolbar"...

Click on little down-arrow just to the right of the Quick Access Toolbar on the top left of a form (eg the form of the appointment you're looking at), then choose "More Commands"...

On the resulting dialogue, select Developer tab in the "Choose commands from:" drop-down list box, then scroll down to find "Design This Form" (note "This Form", not "a Form...". Select that command, click on Add, then OK out of the customize dialogue.

Now you have a little icon supposed to represent designing actions (pencil, ruler, set square) in your toolbar:

Click on the icon and you get into the form designer, with the current item being loaded. You'll see a bunch of tabs - these correspond to "pages" within the form, and any in brackets are hidden. Select the "All fields" tab, choose Date/Time fields from the drop-down (or try "All Appointment fields").

You should now see just the date fields, including the original creation date...

This might seem a real palaver, but once you have the icon on the QAT, it's a 5 second action to show the dates... and can be very handy :)

The lost art of the OOF

Ewan — Sun, 30 Dec 2007 01:10:02 GMT

Some time ago, I posted about how the ".sig" has faded from grandeur. I'd like to add the somewhat terminal dryness of the OOF message to that list, and propose a solution.

OOF is a Microsoft term for Out of Office. It should really be OOO, but is stuck in the days of the predecessor to MS Mail and Exchange. See http://msexchangeteam.com/search/SearchResults.aspx?q=oof for myriad stuff on OOFs, and here (on why it's OOF and not OOO) for one of the first - and for a while, most-read - blog posts on the Exchange team blog.

I've seen a lot of OOFs in my time, and many are of a hugely unimaginative nature. Some are kind-of smart in that they convey the most information in the shortest amount of characters (eg "oof til 7/1 - mail jbloggs if urgent") whereas some have clearly been lovingly hand crafted.

When I worked in the Exchange product group, I sent a mail to one particular guy (who is ex-pat Brit but had been over in Redmond for some time) on the 16th December. Turns out, he'd gone "home" for "the holidays" and I got:

I am so on vacation. By the time I get back, I expect things will look different. See you on 1/17/05. I probably won't ever read your email. Sorry.

There's something refreshingly honest about that - it's admitting that he's not going to be on email for at least a month, by which time, anything he got sent in email will be out of date. Brilliant. Helps build a case for Instant Messaging if you ask me.

Probably the best OOF I've seen came from a somewhat eccentric Canadian (who once replied when I mentioned I'd seen him the previous evening in New Orleans, clearly having a Nice Time), "oh yeah... any night when I don't end up in jail has to be a good night"). Enjoy...

It happened. I knew it would happen some day, but never dreamed it would happen so soon. I tried to hide it from everyone, but word got out and boy did I catch hell for it. Yes, as embarrassing as it is, I must confess before God and country that I was caught, red-handed, Getting Productive Work Done In The Office!

People, please: do try to control your Shock and Horror. I know we used to do real work Long Ago, but we've moved past that, haven't we? It was an honest mistake; an accident in the truest sense of the word. I did my best to hide it from everyone and thought I was successful around the children and my more-dense co-workers. But there is only so long one can live a charade, and in the end, like a house of cards in a hurricane it came down, down, down...

To pay for my egregious act of productivity and practical effort, I've been sentenced to two days of offsite meetings by a jury of my direct management.

Yes, kiddies, that is Two Whole Days of unbridled Tag-Teaming, Outlining, Problem-Solving, Situation-Analysing, Team-Building, Proactively-Leveraging, Federating, Brainstorming Facilitation and Group Contemplation. Unpack the markers and the big pads of paper, Martha: we is gonna have an offsite!!

Can you already feel the sweat drip slowly down ewers of water; the ice cubes grumbling with frustration at their inevitable doom in a pastel room filled with inoffensive Corporate Art? Can you see the elegant buffet of Northwest Grilled Salmon Medallions lounging in a Light Cream Sauce over chirping steam trays, accented by a tossed salad of Garden Fresh Greens? Can you hear that first person raise their hand to state, two hours into to the discussion, that "Before we go any further, we need to define the problem" only to be followed seconds later by another person wondering "what are the criteria for success?"

Do you get the idea that at some point on the first day, I'll be screaming out "BINGO!" to a very confused audience?

Ah; they're used to it...

A co-worker once told me you could solve any team problem with a case of malt liquor, an afternoon of skeet shooting and a strip club. He's no longer employed at the company (something to do with an offsite of his own gone terribly awry near the Montana state border) but I think he was on the right track.

Where I am going, there are no visiting hours, and even worse: no conjugal visits. I might be reachable at <number>. Heck, if it's really important, email or text me. Rumour has it the gardener can smuggle those in hidden in his watering can...

See you on The Other Side,

ian

Now I ask only one thing. We must all put some degree of (professionally relevant) imagination into our OOFs. It's only respectful to the poor sods still at work who're sending us email whilst we enjoy a few days out, isn't it?

Have a Happy New Year, everyone. And please, for the sake of the rest of us, make your OOFs mean something special. Or funny. Or whatever.

Bulk update Outlook Contacts' phone numbers to be E.164 compliant

Ewan — Fri, 30 Nov 2007 12:10:29 GMT

Here's a quick & dirty tool I put together for Outlook to be able to update all the phone numbers of contacts to make them E.164 compliant. It relates back to a post a while back around the challenges of formatting numbers 'correctly', particularly important once you get into using click-to-dial technologies such as Office Communication Server.

The tool itself is basic since it's only really expected that people will run it once, to sort out the numbers of old contacts you might have. It will check all the contacts in a given folder and automatically fix the numbers up, but there are a few caveats...

It's hard coded for UK numbers beginning +44 ... though the code is pretty easy to get to if you know anything about Outlook forms, and you can modify it at will.
It doesn't back up the contacts before modifying, so you might just want to copy your Contacts folder somewhere else before running, if you're of a nervous disposition. I can verify that it hasn't mangled any of my contacts and nobody in Microsoft who's tried it has reported a problem.
It's not exactly straightforward to install - but if you follow the instructions carefully, you'll be OK.
The document in the ZIP file explaining how to install & run it, is in Word 2007 format (docx). If you still haven't either upgraded or installed the compatibility pack to add OpenXML support to your older version of Office, there's a link in the ZIP file to go straight to the download page.

A final word: this is completely unsupported, supplied "as is" etc. If it does mangle all your contacts up, just revert to your backup copy - and if you didn't take a backup then you've only got yourself to blame.

Harsh but fair I think :)

Enjoy.

The logic converts "from" the format on the left to the format on the right... (_ denotes a space)

Old format number begins	New format number begins
0	+44
(0	+44 (
+44_0	+44_
+44(0	+44(
+44 (0)	+44
+440	+44
(0)	+44_

Examples

old number	New number
0118 909 1234	+44118 909 1234
(0118) 909 1234	+44 (118) 909 1234
+44 0118 909 1234	+44 118 909 1234
+44(0118) 909 1234	+44(118) 909 1234
+44 (0)118 909 1234	+44 118 909 1234
+440118 909 1234	+44118 909 1234
(0)118 909 1234	+44 118 909 1234

Careful what names you give to Outlook Contacts when using UM!

Ewan — Mon, 05 Nov 2007 12:45:29 GMT

This is a follow up to Friday's post about what happens if you have Exchange Unified Messaging set up to send you notifications on missed call alerts (and on voicemail), using caller-ID to reverse lookup against the personal contacts folder.

Stephen Spence commented:

Fingers crossed nobody is using silly names for any of their contacts and finds out about this the hard way!

And he's absolutely right - I tried renaming the contact I have for my wife (to "Mrs D!"), then called my desk number (whilst OOF was on), from her mobile.

Here's what she got (viewed in her mailbox via Exchange 2003 OWA):

Just as well I wasn't calling her "Trouble & Strife" or something like that :)

So, be careful... if you have UM and external OOF turned on, don't add people into your contacts with disparaging names in case they happen to phone you one day and find out, as Stephen says, the hard way....

I learned a cool thing about Exchange UM today

Ewan — Fri, 02 Nov 2007 17:22:00 GMT

I've seen this behaviour in practice before, but I don't think it really clicked with me until Neil May from PostCTI (who was hosting our penultimate Exchange Unplugged event today) told me how pleased he was with it.

This functionality concerns the "missed call notification" feature of Exchange Unified Messaging - as well as the server telling you that you have a new voicemail, it will also tell you when someone has connected to UM but hung up before leaving a message.

In both cases (ie when someone leaves a message, or if they hang up beforehand), if the server can identify their caller ID as belonging to someone in your contacts, you'll see the voicemail or the missed call notification as if it came from the person themselves (it's actually Microsoft Exchange on behalf of <the caller>, but it primarily shows as if it came from the person directly).

So in this case, if I hit "reply" to the notification, it will send an email to the person that was identified as the source of the message. Cool, yes.

What's nice, though, is that if I have my Out of Office message set, and someone calls me then either leaves a message or hangs up, when the notification lands in my Inbox and appears "From" them, their email address will be sent the Out of Office message I've set.

As it happens, I have a contact entry for my own mobile number, in my Outlook contacts folder, but set with my Hotmail email address. When I call my office extension from the mobile, it identifies the contact as the source of the call, and the return address is the Hotmail one, so the Out of Office message I set on my mailbox will be sent to the Hotmail account, since I had associated the mobile number that called me, with that address.

Neil (who spends a lot of time on the road) said this was one of the most unexpectedly cool parts of Exchange UM - customers who call him up and don't leave a message (but who he's already added to his Outlook contacts), will get the Out of Office message as if they'd sent him email. So the next question they ask him is, "How can I get that for myself??"

Seeing this in reality brings the technology alive in a lot of users' eyes.

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.

Keep the Item count in your mailbox low!

Ewan — Thu, 09 Aug 2007 13:05:36 GMT

I've been doing a little digging today, following a query from a partner company who're helping out one of their customers with some performance problems on Exchange. Said customer is running Exchange 2000, and has some frankly amazing statistics...

... 1000 or so mailboxes, some of which run to over 20Gb in size, with an average size of nearly 3Gb. To make matters even worse, some users have very large numbers of items in their mailbox folders - 60,000 or more. Oh, and all the users are running Outlook in Online mode (ie not cached).

Now, seasoned Exchange professionals the world over would either be shrugging saying that these kind of horror stories are second nature to them (or fainting at the thought of this one), but it's not really obvious to the average IT admin *why* this kind of story is bad news.

When I used to work for the Exchange product group (back when I could say I was still moderately technical), I posted on the Exchange Team blog (How does your Exchange garden grow?) with some scary stories about how people unknowingly abused their Exchange systems (like the CEO of a company who had a nice clean inbox with 37 items, totalling just over 100kb in size... but a Deleted Items folder that was 7.4Gb in size with nearly 150,000 items).

Just like it's easy to get sucked into looking at disk size/capacity when planning big Exchange deployments (in reality, it's IO performance that counts more than storage space), it's easy to blame big mailboxes for bad performance when in fact, it could be too many items that cause the trouble.

So what's too many?

Nicole Allen posted a while back on the EHLO! blog, recommending 2,500-5,000 maximum items in the "critical path" folders (Calendar, Contacts, Inbox, Sent Items) and ideally keep the Inbox to less than 1,000 items. Some more detail on the reasoning behind this comes from the Optimizing Storage for Exchange 2003 whitepaper...

Number of Items in a Folder

As the number of items in the core Exchange 2003 folders increase, the physical disk cost to perform some tasks will also increase for users of Outlook in online mode. Indexes and searches are performed on the client when using Outlook in cached mode. Sorting your Inbox by size for the first time requires the creation of a new index, which will require many disk I/Os. Future sorts of the Inbox by size will be very inexpensive. There is a static number of indexes that you can have, so folks that often sort their folders in many different ways could exceed this limit and cause additional disk I/O.

One potentially important point here is that any folder, when it gets really big, is going to take longer to process when it fills up with items. Sorting or any other view-related activity will take longer, and even retrieving items out of the folder will slow down (and hammer the server at the same time).

Oh, and be careful with archiving systems which leave stubs behind too - you might have reduced the mailbox size, but performance could still be negatively affected if the folders have lots of items left.

Plain text, RTF or HTML mail?

Ewan — Thu, 02 Aug 2007 11:25:58 GMT

Here's an interesting question that I was asked earlier today; I can't offer a definitive answer, but these are my thoughts. If you have any contradictory or complimentary comments, please comment or let me know.

"Can RTF/HTML Mail be as safe as plain text with regard to viruses/malware etc?"

Theoretically, I think plain text will always be safer since there’s less work for the server to do, and there’s no encoding of the content other than the real basics of wrapping up the envelope of the message (eg taking the various to/from/subject fields, encapsulating the blurb of body text, and turning it into an SMTP-formatted message).

Where things could get interesting is that plain text still allows for encoding of attachments (using, say, MIME or UUENCODE), which could still be infected or badly formed – so the risk level of attachments is technically the same (although in an RTF or HTML mail, the attachment can be inline with the text, which might mean the user is more likely to be lured into opening it, if it's malicious).

There may be some risks from a server perspective in handling HTML mail which mean that a badly formed message might be used to stage a denial of service on the server itself. I heard tell of a case a few years ago when a national newsletter was sent out with a badly formed HTML section, and when the Exchange server was processing the mail to receive it, the store process crashed (bringing Exchange to its knees in an instant).

The downsides with that scenario were:

The message was still in the inbound queue, so when the store came back online, it started processing the message again and <boom>
This newsletter was sent to thousands of people, meaning that any company that had at least one person receiving that mail, had some instant server-down until they identified the offending message and fished it out of the queue.

This bug in Exchange was identified & fixed, but there’s always the theoretical possibility that since the formatting of an HTML message is more complex, there could be glitches in handling the message (in any email system).

Plain text mail is ugly and so lowest-common-denominator, it’d be telling everyone to save their documents as .TXT rather than .DOC or .PDF.

RTF mail works OK internally, but doesn’t always traverse gateways between Exchange systems, and isn’t supported by anything other than Outlook (ie mailing a user in Domino, they won’t see the rich text).

HTML mail may be slightly larger (ie to do the same content as you’d do with RTF takes more encoding and it’s sometimes a bit bigger as a result), but it’s much more compatible with other clients & servers, offers much better control of layout and traverses other email systems more smoothly.

I'd say HTML mail is the obvious way to go. Anyone disagree?