Helping the Kid's Help Phone - Exchange Deployment

It has been a while since I posted an update on the Kid's Help Phone project.  It is not because we've been slacking but I've been away with little time to catch up with Ted and Neil.  Well I am back and met with them a week or so ago and things are humming along nicely.  I left off with the server specs for the new Exchange 2007 Server but since then....

Exchange 2007 has been deployed (in fact SP1 planning is underway).  It was a pretty smooth process overall with the configuration and deployment being pretty straight-forward (no existing Exchange infrastructure to deal with).  After discussing the options regarding Storage Groups and databases as well as new features such as Local Continuous Replication we decided on the following disk layout.  We started with 1 TB or disk space in a RAID 10 array.  RAID 10 usually provides the best performance on an Exchange server and since we only had enough room for one array that was the choice we went with.  We broke that down into the following rough partition sizes.....

  • C:\ 25GB for the OS and applications
  • D:\ 10GB for transaction logs
  • E:\ 465GB for the databases
  • F:\ 10GB for LCR transaction logs
  • G:\ 465GB for LCR databases

Now in a perfect world we would have the LCR databases and transaction logs on a separate drive array but again we were limited to the space we have.  This allows us to take advantage of some of the features of LCR while relying on traditional backups for the rest or the DR plan.

With this in place and Exchange installed the next step was to sort out the users into a few groups so that we could minimize downtime for critical email users in case of disaster.  We did this by splitting the users into four groups (logically) and placed the users mailbox into the appropriate Storage Group.  By doing this, in the event of a disaster, we can restore a smaller Storage Group with a 20GB database that contains all the critical users faster than we could restore a 200GB database with all the users.  Once the critical users are online we can go down the priority list and get everyone else back online in a staged manner.  There is a really good article that a friend of mine and Exchange MVP wrote on disaster recovery in Exchange 2007 if you are interested.  (Hint: It is better to read it now, then when the disaster has happened and you are trying to fix it :) )

The last step was migrating all the users to the new system.  The previous email system was a mix of ISP provided POP3 services and a 3rd party web based email tool.  For the users on the POP3 based system it was pretty straight-forward, export to PST, reconfigure the mail settings and import the PST.  For the users on the webmail system it was still straight-forward but a little more time consuming.  Because they had no Outlook profile set up, and they accessed everything through a web interface, migrating the mail was a bit more difficult.

The first step was to configure the webmail server to accept IMAP connections.  From there they configured Outlook profiles for all the webmail users (around 75) and connected to the old mail system.  From there they could export to PST, reconfigure the profile to connect to Exchange and then import the PST.  Time consuming? Yes.  Boring, I assume so but I was on the road :)  But it worked and again they were able to stage it to roll out OWA to the more critical users before moving down to the less critical users.

So now it has been a few months and the users love the new system.  The favourite feature among the users?  The calendaring improvements and scheduling assistant which allows them to schedule a meeting in a few minutes.  Something that used to take hours and non-stop emails to do previously.

Up next, SharePoint and Office 2007!