Border Lines in Word & Outlook

Posted on December 12, 2008 by ewand

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

Posted on April 21, 2008 by ewand

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

Posted on December 29, 2007 by ewand

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

Posted on November 30, 2007 by ewand

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!

Posted on November 5, 2007 by ewand

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

Posted on November 2, 2007 by ewand

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

Posted on September 24, 2007 by ewand

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!

Posted on August 9, 2007 by ewand

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?

Posted on August 2, 2007 by ewand

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?

Exchange mailbox quotas and a ‘paradox of thrift’

Posted on July 10, 2007 by ewand

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).