Sizing Exchange 2007 environments

I’ve had a couple of conversations with customers lately, looking for advice in figuring how to plan and size their Exchange 2007 design. In planning for something as potentially complex as a large messaging system, it’s easy to get dragged into deep technical discussions around the number of spindles of disk, the IO requirements, how to build the clusters etc etc… but sometimes a high-level overview needs to be presented to get the process moving.

I’d recommend a first step would be to look through some of the excellent posts on the Exchange Team Blog, especially around planning the processor and memory requirements or the disk subsystems. Some of the content from the blog has been published as part of the Planning & Architecture documentation on Technet – some of which provides a great overview of the server deployments required for different scales and complexities of environment.

When it actually comes down to “how many servers will I need?”, the question is always a tricky one to answer since it very much depends on where the users are, what they’re doing and how much data (and growth of data) you expect to see. HP have recently published some guidance on sizing HP specific hardware, which would be well worth reading if you’re going to deploy their kit, but still may be worth a look if you were going to use someone else’s.

There’s a good whitepaper and a series of useful tools which can take fairly straightforward inputs and give you an estimate (and price, in US$) of what hardware you’ll need. They even have some “off the shelf” configurations which are sized at set user levels – of course, it may be more complex to deploy a highly available, well managed environment, and there’s no substitute for experience when it comes to designing something like this, but it could be a great start.

The lost art of the .sig

Whatever happened to elaborate and amusing ‘.sig’s? It used to be common practice to have a signature with some kind of witty/pithy quote appended at random to every email.

Nowadays, the autosignature that most email programs can insert (such as Outlook’s ability to have multiple autosigs, which vary depending on which account is sending, or whether the mail is a new message or a reply), is typically informative with lots of contact information, job titles, disclaimers etc. I’ve seen some sigs which are twice as long as the message itself (though there may be a legal requirement in the UK to put company information in the sig, in the same way that letterhead paper would, but some people really go to town).

I’ve had a lot of people comment on my own sig (or steal it – you’re welcome to, if you like), since I tried to make it as small as possible whilst still conveying the maximum information, and using hyper links for the different ways you can contact me:

Ewan Dalton
communicator email phone RSS | +44 118 909 3318 | ewand@microsoft.com
Solutions Architect – Microsoft UK
cid:image001.jpg@01C6A4F4.036E8CF0  Sent using Exchange 2007 and Outlook 2007
Microsoft Limited | Registered in England | No 1624297 | Thames Valley Park, Reading RG6 1WG

or for replies (where real estate is even more important)…

Ewan Dalton | communicator email phone RSS | Microsoft UK | ewand@microsoft.com |+44 118 909 3318
Microsoft Limited | Registered in England | No 1624297 | Thames Valley Park, Reading RG6 1WG

Since we’re using Office Communicator, if someone clicks on the first link (the sip: URL), they’ll send me an IM. The 3rd pic (the tel: URL) will call me using Communicator (or whatever else they’re using that can support a telURL, such as a Smartphone).

I kind of miss the days where interesting quotes were de rigeur – you know, the kind of thing about BillG saying 640k should be enough for anyone (I’m not actually sure he ever said that, but we’ll leave it for now) or Thomas J Watson saying there should be a worldwide market for maybe 5 computers…

Speaking of Thos J Watson, if you have an idle few minutes, you really should check out the IBM Songbook – top marks for IBM to keeping it alive as historical curio in the IBM Archives. My own personal favourite is “To Thos J. Watson, President, I.B.M.”, sung to the tune of “Happy Days are Here Again”.

Anyway, last word on .sigs. David Harris, author of the now venerable Pegasus Mail (which had support for auto-insertion or random quotes from a .sig file, used to have a cracker or two. One that sticks in my mind (apparently taken from a real newspaper):

After the boat had been secured above the wrecked galleon, the diving apparatus was set in motion by the Captain’s 18 year old daughter, Veronica. Within hours she was surrendering her treasure to the excited crew.

Thread Compressor for Outlook – do you want it?

Here’s an appeal – nearly 8 years ago, I wrote* a little COM addin for the-then new Outlook 2000, which “compressed threads”. The idea was that it could take an email thread (eg a discussion over a period of time and a number of responses, from any number of people, and typically sent to a distribution list for the purposes of discussion), and compress that thread down to the salient points. It has evolved over a few iterations since but has been largely dormant for the best part of 5 years – it does everything I need it to do, so I’ve never developed it any further (and if truth be told, a hard disk crash blew away the source for the last version and I could never face going back to a previous beta and re-developing the changes I’d made).

I’d like to understand if anyone else would like it.

The basic assumption with Thread Compressor is that when people reply using Outlook, they tend to add all their comments at the top – some do inline replies, but most eschew that – and don’t edit the original contents. If this assumption holds true, then it would be possible to compress all discussion threads down to only holding onto the final email or the final post (to a public folder) since it will contain the entire history of that branch of the thread. Of course, there may be multiple branches of the thread, and Thread Compressor handles that.

The first time many people run TC on a large folder, it will routinely get rid of 50% or more of the content, so proves useful in slimming down folders where you archive stuff, or folders where distribution list contents are sent by Outlook rules, never to be read but to be indexed by Windows Desktop Search or similar.

In my last run, I scanned almost 1Gb of email and the Thread Compressor discovered about 21Mb of mail which could be removed… not quite as dramatic as 50%, but it saved me reading over 1,000 emails and it reduced my mailbox size a little…

There are a few obvious benefits to thread compression…

  • It reduces the size of your mailbox, so keeps you under-quota
  • It removes spurious email so you have less stuff to plough through
  • When searching, it reduces the number of hits since it won’t return every mail in a thread which contains the same word(s)

… but some obvious potential downsides…

  • The assumption at the top of this post. If I reply to someone’s email, but change the contents of their original message in the reply, then TC will retain the modified version and it will look like the originator really said that. There may be ways to work around this limitation now, but I never bothered to figure them out.
  • Legal compliance – maybe you need to keep a copy of every mail for compliance purposes: if so, users programmatically deleting messages could be a *bad thing*.
  • erm, can’t think of any/many more…

If you think this kind of functionality should be either built into Outlook or available as an opt-in addon, then please let me know. We have many thousands of regular users of Thread Compressor inside Microsoft. It would be cool to think of millions more outside as well…

//Ewan

* The really smart bit of TC was actually put together by a guy called Peter Lamsdale. All I did was take his algorithm – which I still have difficulty understanding much less explaining – and strap a UI around it. An earlier version of TC was published (unofficially) on a website and an article was written about it by Evan Morris. There is even an unconnected MSDN bit of sample code which is nowhere near as effective (IMHO)

Blackberry outage – worrying for mobile mail junkies

I just read news of an 11-hour outage in RIM’s Blackberry infrastructure on ZDNet – ouch. Not only did email stop flowing to the devices during the outage, but the backlog of mail which built up is taking time to clear.

Without wishing to gloat (really), users of Windows Mobile devices for push email wouldn’t suffer something like this (with the possible exception of their mobile carrier having a major network outage, which would affect Blackberry users as well and would be unlikely to last so long). Once you’ve deployed a real mobile mail solution, having any kind of serious outage is a worrying thing – especially if users are giving up laptops in order to rely on their mobile devices…

There are some architectural documents which outline the approach to using Windows Mobile and Exchange – such as the one in the Deployment Guide.

If you’re interested in how Direct Push works, you’d do well to check out these posts on the Exchange Team blog too:

Outlook 2007 update – performance improvement on large PST/OST files

I’ve been beta-testing this update for a little while and it seems to make quite a difference to the performance of Outlook 2007 (especially at startup) when you have large PST files, or a large offline cache of a mailbox. The Outlook team released it live, yesterday.

http://support.microsoft.com/kb/933493

I’d highly recommend giving it a go – it’s one of those updates where you might not really notice much positive improvement after you’ve installed it, but you do notice that there are less of the times where you notice there’s a performance problem 🙂

When interaction design goes bad

For various reasons, I’ve been testing & driving several different cars lately, a process I quite enjoy – getting to know the foibles of the car’s cockpit, playing with the various toys and gadgets, as well as actually learning how to drive each one according to its size, performance etc. It’s really pleasing to find a well thought out design in some bit of car UI (Audi’s MMI system is just sweet), but even more frustrating that some companies can spend $100ms developing a car but overlook some really basic functions which will just make the driver crazy (like the clock which looks very smooth and lovely but has no obvious way of adjusting the time… I’m currently driving around in a loan car which is 1 hour adrift of real time because I haven’t figured out how to move the clock forward to Daylight Saving Time, and haven’t yet gotten around to RTFM).

Thinking about all of this reminded me of two great books which, if you’ve any interest in design at all, I’d highly recommend. I’ll do this review in 2 parts, this one being, as it is, part one.

The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity

The Inmates Are Running the Asylum: Why High-tech Products Drive Us Crazy and How to Restore the Sanity Alan Cooper

This is a fascinating book which talks about the doom-laden scenario of everything we use being computer controlled (and since the book was written around 10 years ago, shows a fairly decent grasp of the future, some of which has already come to pass), discusses the design of User Interaction, and a model which Cooper has used successfully for a number of years, centred around “Personas”.

Note the use of the term User Interaction as distinct from User Interface (UI)… in this case, we’re talking about the whole way that people interact with a system or device, not just the UI of the software – extending the user interaction model to include only as much information as required, without being stupidly modal (eg the same button doing different things at different times based on what mode a device is in, especially bad when the device doesn’t make it obvious what its mode is).

 

A great example of good user interaction is the iPod – good UI in software, but it works so much better because the device complements it totally. Bad user interaction design is evident in many remote controls – they have lots of identical buttons with confusing labeling (what *do* all those symbols mean?) and the software they’re controlling on the TV/DVD player etc, is sometimes less than intuitive and not helped at all by having a control that needs the manual to be open in front of the user to make any sense.

There’s one great example of good design that jumped out from reading the book – and that was Cooper’s commission to design an interaction model for a new airline video on demand (AVOD) system. Various attempts were made to get something that could display quite a lot of possible options (since there were many films & TV shows which could be watched at the user’s demand), without having to give any instruction on how to use the thing, even to people who weren’t familiar with what they might expect on modern consumer electronics or computer systems.

After selecting and rejecting various ideas, Cooper settled on a simple UI of a rotary dial positioned directly below and in the centre of the screen, combined with thumbnail views of the film/show. Show someone a rotary dial or knob (suitably designed – maybe one with serrated edges and no obvious way to pull it out) and they’ll instinctively turn it before trying anything else. (This is a topic also covered by the 2nd book in this series: it deals with how a device naturally affords itself to the user – eg if you pick up something with a single, raised button, your first instinct would be to press it rather than try and pull it off – it affords being pressed more than being prised).

If the user turns the dial back and forwards, the list of titles pans that way, and if they turn it more quickly, the list moves quickly. When they find something they want to watch, they press the button. End of user interaction model.

Again, note the distinction between user interaction and UI. As far as the user is concerned, they turn the dial and push it to pick stuff. The UI can later deal with minutae like what to do if the user selects something by mistake… how do they go back? How do they control the volume or screen brightness etc? Maybe other buttons or controls might be required for that… unless they got into some modal system where the dial would control volume… but that could just confuse things more than adding an extra button or two.

Alan also introduces Personas as a key way of focusing designers and developers on how to address the specific needs of a specific type of user; rather than being generic (“the users”, or even saying retired people, or young mothers, or teenagers or tech-savvy twentysomething males, is still vague), the concept means they actually embody a persona with characteristics as if it’s someone they really talked to – here’s John, he works in a small business IT provider, so he knows a good bit about technology but lacks the time to do lots of reading about how to implement it, etc etc.

The Exchange development group in Microsoft was one of the no-doubt many who have adopted personas when it comes to designing software – so the needs of a whole group of disparate people can be met, hopefully, by using more holistic design processes, than simply concentrating on making it look and function well to the people who’re doing the designing.

More info on Alan Cooper’s personas

Adjunct: There’s an amusing article courtesy of SAP, on Golden Rules for Bad User Interfaces – if you’re going to sit down and design a really bad UI, follow these rules and you won’t go wrong…

Hosting of applications – the inevitable future?

I’ve been musing over some medium term IT trends lately and one idea that keeps coming back into frame is the seemingly inevitable trend towards hosting of applications. Take Exchange, as just one example…

Hosted Exchange* has been available for years, from lots of different providers all around the world. The basic concept is that instead of buying the software, you just buy the service from a hosting company much like you buy line rental on your phone, or internet access from your ISP. Why not just have your company’s email sitting somewhere else, and save yourself the hassle of managing it?

*Hosted Exchange is not to be confused with the somewhat confusingly named Exchange Hosted Services, which is all about hosting the route to get mail into and out of your own email environment. EHS was formed by the procurement of Frontbridge, who had established a good name in hosted filtering… ie the MX record of your domain actually delivers mail to their datacentre, they scan it for spam and viruses, and the remaining “hygienic” mail is delivered down to you.

So what’s stopped everyone from adopting Hosted Exchange before? I suppose the cost is one thing – if you had 500 users and it cost, say, £10 a month to provide each of them with a mailbox, you’d be seeing £5k going out the door every month, and might think “surely I can provide the same service, in house, for less than £60k a year?”, and you might well be right. But start to dig into the detail, and it could be a lot closer… Think about buying:

  • the hardware (maybe £10k worth of servers, and any amount of money could be spent on storage, but let’s assume £15k),
  • the software (at full price, this could work out at something in the order of £30k for that kind of user population)
  • additional software, like anti-virus, anti-spam (if you didn’t want to just use what’s in the box in the shape of the IMF etc), backup software, archiving systems etc etc

… and then add in the time and expertise required to set it up and keep it healthy long-term, then maybe it is less expensive to do it all in house. But by hosting the application, you could free the time to do other stuff, or just have one less thing to worry about… especially in times when security threats can sap administrator time, and compliance requirements could mean lots more red tape and requirements for recoverability, let alone high availability.

I’ve seen various analyst reports which reckon that 70% of an average IT budget is spent just maintaining the status quo and keeping existing systems running.

As connectivity gets better and better, it seems almost inevitable that a “normal” Exchange deployment in a few years will actually be hosted by someone else. Of course, there are several models which could be adopted:

  • Hosting company just operates your own servers/software for you. I’ve seen this lots of times already, in the shape of IT outsourcing where the “hoster” is just a drop in replacement for an in house IT operation, and maybe even takes servers that were previously operated in house and moves them to their own datacentre for ongoing management
  • Hosting company provides your servers for you. This is a little less common, but growing – namely, the hoster has their own kit but they dedicate a given server/bank of servers just to you.
  • Hosting company just provides “service”. In other words, you get a mailbox of a given size, but don’t need to care how it’s provisioned. This is going to be more appealing to smaller businesses, maybe.

So what else? Sharepoint? Yep, you can do that too, as part of the snappily-titled Microsoft Solution for Hosted Messaging & Collaboration v4.0.

And what about after that? I could see the day when some companies want IT as a turnkey service just like they look at other utilities – you buy the bit of cable and down that comes whatever services you’re subscribed to, and you can add and remove services at will, just like you can with satellite or cable TV.

Want your phone system to be hosted and connected to by the same bunch of ethernet cables? No problem. Intranet applications and portals? Sure… I wonder where it’ll all end? Hosted desktops?

Is your email compliant with the (UK) Companies Act?

A semi little-known fact… as of the 1st January 2007, the rules for UK companies regarding business stationery changed. Just like every registered company is bound to include certain information (the registered office, the geography of registration (eg England & Wales) and its company registration number) on all its official letters & order forms, electronic communications now fall under this rule.

As Companies House says:

Whenever an email is used where its paper equivalent would be caught by the stationery requirements then that email is also subject to the requirements.

I can honestly only think of one case where a company includes all this stuff in their email, along with a long-winded disclaimer. I suppose the rules are now in place and people are waiting to see how they’re interpreted… might be worth thinking about including your details on your own e-mail .sig…

There’s quite a good discussion of the whole area on legal eagles Pinsent Masons site, here.

Oh, and did you know that Exchange 2007 now has the ability to include standard disclaimers on all mail that passes through it? For a step-by-step illustration, have a look over on msexchange.org.

Shortcut to quickly set your voicemail greeting in Exchange 2007 UM

I love the Exchange UM system my voicemail is supplied by, though it can take a while to navigate using voice commands if all you want to do is set your voicemail greeting. I (like a lot of people in Microsoft UK) set the greeting every day to set expectations of what I’m doing, and when I’m likely to pick up voicemail.

Using this dial string, create a new contact on your phone and set it with a speed dial (obviously, I use a Windows Mobile device, but the same concept should be possible on any mobile):

accessnumber pextensionpPIN#006212

eg. +44 1234 567890 p2468p0123456#006212

This takes you straight to the “record your greeting after the tone” prompt, and after your greeting is recorded, press the # key and it plays back to you. If you don’t want to listen to the greeting but just accept it, press “1” or “2” if you messed it up and want to re-record.

Exchange 2003/2007 clustering & high availability

The Exchange development team have done a nice job of expanding the high availability options with the 2007 release. With Exchange 2003, the only real HA design was to use what is now known as a Single Copy Cluster (SCC) – ie. there’s one copy of the databases and log files, held on a Storage Area Network, and multiple physical cluster nodes connect to that SAN. Exchange 2007 introduced Local Continuous Replication and Cluster Continuous Replication, and is due to add Standby Continuous Replication later this year.


In the 2003 model, the “Exchange Virtual Server” (EVS) was a collection of resources that run on one of the physical cluster nodes at any given time, with each EVS having its own name and IP address which the clients connected to.



This model works well in providing a high level of service for clients – Microsoft’s own IT department ran an SLA of 99.99%, a maximum of 53 minutes of downtime a year. Routine maintenance tasks (like patching the OS, upgrading the firmware etc) could be performed one node at a time, by having the workload fail over to the passive node during the maintenance period. The downside with this single-copy approach is that there’s a single point of failure: the disks. Even though the SAN technology is highly fault tolerant, it’s still possible to knock out the entire SAN, or to have some catastrophe make the SAN corrupt the data on the disks.


Exchange 2007 added a couple of additions to the high availability arena – Local Continuous Replication (LCR), which doesn’t use clustering at all, and Cluster Continuous Replication (CCR) which does. The name “Exchange Virtual Server” used in clustering has also changed to “Clustered Mailbox Server” to prevent confusion with the Virtual Server software virtualisation technology.


Local Continuous Replication


In an LCR environment, the server keeps a 2nd copy of its databases and log files on a separate physical set of disks, which could be in the same place (maybe even a USB disk hanging off the back of the server, if it was a branch office or small business one). Basic Architecture of Local Continuous Replication


LCR could also replicate data to another datacenter using iSCSI storage, accessed over the WAN (assuming the bandwidth and network latency are OK). Downsides to LCR are that the server in question is doing more work (by keeping two separate sets of disks updated) and that there’s no automatic failover – an administrator would need to manually bring the LCR copy of data back online, in the event of a hardware failure of the server.


Cluster Continuous Replication


CCR provides a more complex but more robust (in terms of recovery) solution. There are two nodes in a cluster (and there can only be two, unlike the SCC approach which could have up to 8 nodes), with each node containing a copy of the databases and the log files being used by the active node. When a log file is closed on the active node, the passive one will copy it over the LAN/WAN and will apply the changes to its own copy of the database. The plus side of CCR is that there’s little overhead on the active node (since it’s not taking care of the 2nd copy) and because we’re using clustering, the nodes can fail over between each other automatically – they maintain a networked heartbeat between the nodes, so the passive node can tell if it needs to come fully online. 



In the case where either planned or unplanned failover occurs, the passive node will take over the role of servicing users, meaning the clients continue connecting to the same name and IP address they were using to previously, and the formerly active node will now take up the passive role, and will start pulling any changes back from the newly activated one.


In order to prevent the situation of both nodes coming online at the same time (something that’s referred to as a “split brain” cluster), there’s also a new “witness” role which is used to prevent the scenario where the passive node thinks the sky has fallen in and everything’s gone dead, when in fact, it’s the passive node that’s fallen off the network. The witness is just a file share, which uses locking semantics to illustrate if the active node is still alive (since both nodes connect to the file share witness) – so if the passive node can read the witness and deduce that the active node is still running, it won’t bring itself online, even if it can’t currently see the heartbeat from the active node.


CCR provides a solution to the single point of failure in the SCC model, but there are some limitations – namely, there can only be two cluster nodes, and they need to be on the same IP subnet. This means it can be tricky to have a node in a Disaster Recovery datacenter, what with needing to span a subnet and an AD site across the WAN. What many people feel would be the ideal scenario would be to have the both CCR nodes & copies sited in one datacenter, but then have a 3rd node in the DR datacenter, on a different subnet.


Standby Continuous Replication


Service Pack 1 for Exchange 2007 (due in the second half of 2007) plans to introduce a new replication paradigm called Standby Continuous Replication (SCR). This could be used in conjunction with a CCR model, where the active/passive nodes are in one place and will automatically fail over between each other, but a third (standby) node is in a different place. Activation of the 3rd node will only take place when both of the primary nodes are offline, such as if the primary datacenter failed completely. In that environment, a manual process will be followed to mount the databases on the standby node, similar to how an administrator would bring a backup copy from an LCR server online. The third node is not a member of the cluster, and will not need to be on the same IP subnet.


SCR will also offer the option of having a standalone Exchange server sending a copy of its data to another standalone server, meaning that cross-datacenter fault tolerance could be achieved without clustering at all, albeit at the expense of a manual failover regime.


More information on High Availability in Exchange 2003 can be found online here, and for Exchange 2007, here. Further details of what’s going to be in SP1 will be posted in the coming weeks to the Exchange team blog.