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.

If you want to get your hands on trial software for the recently-released Office Communications Server 2007 and its client, Office Communicator 2007, then you're in luck...

• OCS trial download (both Standard & Enterprise editions)
• Communicator trial

Bear in mind that these trials are for tyre-kicking and lab testing only - don't put them into full blown production. They will also expire in 180 days, though can be upgraded to the released and fully supported code.

Here's a funny - it happened a while back, but I was sent a link to this story today. The author kept her laptop in the oven when she wasn't at home, since it was a high-crime area and it seemed a non-obvious place for a laptop to live...

Then one day she came home and her partner was cooking french fries... and presumably hadn't looked in the oven before switching it on :)

I suppose it makes a change that the laptop was melted by external factors, rather than the battery causing some internal pyrotechnics.

Even more amazing: the thing booted up and worked just fine!

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?

... (and sometimes you probably suspect you paid too much)

A common trait in western cultures is the eye for a good deal - you know, getting two-for-the-price-of-one, or thinking that it's worth buying something because it's on sale and you'll save 25%, rather than because you really need it or wanted it beforehand.

I saw a quotation the other day which set me thinking... John Ruskin, a leading 19th-century English artist, all-round intellectual and writer on culture & politics, said:

"There is hardly anything in the world that someone cannot make a little worse and sell a little cheaper, and the people who consider price alone are that person's lawful prey. 

It is unwise to pay too much, but it is also unwise to pay too little. 

When you pay too much, you lose a little money, that is all. When you pay too little, you sometimes lose everything because the thing you bought is incapable of doing the thing you bought it to do. 

The common law of business balance prohibits paying a little and getting a lot... It can't be done.

If you deal with the lowest bidder it is well to add something for the risk you run. 

And if you do that you will have enough to pay for something better." -- John Ruskin (1819-1900)

This is something that maybe executives at Mattel toys are mulling over right now, but it's probably a valuable lesson to any consumers about the risk of going for the absolute cheapest in every sense, regardless of price point.

There's probably an economic principle to explain all this, but I've no idea what it's called

As it happens, I've been getting back into cycling recently and that's required me to spend a great deal of time and money poring over bikes & accessories, whilst learning about all the differences between manufacturers, model ranges etc.

In short, they're all much of a muchness. Just like computers, consumer electronics, or cars - is last year's model really so inferior to the all-shiny new one, that it's worth paying the premium for the up-to-date one? And how can a single manufacturer make such a huge range of related product and still retain its aspired brand values? (quality, excellence, durability, performance, blah blah blah)

I've pretty much come to the conclusion that for any individual at any point in time, there is a point where whatever it is you're looking at is just too cheap, too low-spec for your needs. Sure, I can buy a mountain bike for £50 in supermarkets or junk shops, but it'll be heavy and not as well screwed together as a more expensive one I might get from a good cycle shop.

There's a similar principle in all sorts of consumer areas - like wine, as another example. It's possible to buy wine at £3 a bottle, but it's going to be pretty ropey. £5 and up and you start getting really noticeable improvements - maybe a £6 bottle of wine could be considered 5 times better than a £3 bottle, though it's unlikely that this will carry on - at some point, you'll pay double and the more expensive product will hardly be any better to most people, but for someone, that might be the mid-point in their curve which would stretch from too cheap at one end, too expensive at the other, with a nice middle flat bit where they really want to be.

The far end of that curve would be the point where buying something too expensive will be wasted - if I only need the mountain bike to go to the shops on a Sunday morning for the newspapers, I could do without a lot of the lightweight materials or fancy suspension that a better bike would have. Ditto, if I'm an average cyclist, I won't need a top-of-the-range carbon bike since it won't make any difference to my "performance" (though try saying that to all the golfers who regularly sink their salaries into buying all the latest kit, without having any meaningful impact on their game).

Maybe it won't be "wasted", but I just won't have any way of judging compared to other products in its proximity - if I'm in the market for a MINI and yet looked at the comparative price difference of a Ferrari and an Aston Martin, I wouldn't rationally be able to say that one is better and worth the premium over the other.

So what does any of this have to do with software?

A two-fold principle I suppose: on one hand, maybe you don't need to buy the latest and greatest piece of software without knowing what it will do for you and why. Or if you do buy the new version, have you really invested any effort into making sure you're using it to its maximum potential?

Look at the new version of Microsoft Office, with the much-discussed "Ribbon" UI (actually, this link is a great training resource - it can show you the look of the Office 2003 application, you click on an icon or menu item, and it will take you to the location of the same command in the new UI).

The Ribbon scares some people when they see it, as they just think "all my users will need to be re-trained", and they maybe ask "how can I make it look like the old version?".

The fact that the Ribbon is so different gives us an excellent opportunity to think about what the users are doing in the first instance - rather than taking old practices and simply transplanting them into the new application, maybe it's time to look in more depth about what the new application can do, and see if the old ways are still appropriate?

A second point would be to be careful about buying software which is too cheap - if someone can give it away for free, or it's radically less expensive than the rest of the software in that category, are you sure it's robust enough, that it will have a good level of backup support (and not just now, but in a few years' time?) What else is the supplier going to get out of you, if they're subsidising that low-cost software?

Coming back to Ruskin: it's quite ironic that doing a quick search for that quote online reveals lots of businesses who've chosen it as a motto on their web site. Given that Ruskin was an opponent of capitalism (in fact he gave away all the money he inherited upon his father's death), I wonder how he would feel about the practice of many companies using his words as an explanation of why they aren't cheaper than their competitors?