I used to do some work for a customer who’s idea of running an evaluation of a new system was to pick one product, put it in, then if it sort of worked good enough to just buy that one. Over the long term some of these choices turned out to be less than ideal.
Microsoft has announced that Service Pack 2 for Exchange Server 2007 will be released in Q3 of this year. The MS Exchange Team has listed some of the key new features in their blog post here.
A welcome addition is the new volume snapshot backup plugin for Windows Server 2008. Currently Exchange Server 2007 cannot be backed up by the built-in backup application that ships with Windows Server 2008. Microsoft announced nearly a year ago that they were working on adding this functionality in a future update to Exchange, which we can now expect in SP2 when it is released soon.
The backup plugin doesn’t operate in the way we’re familiar with in previous version of Windows Server when backup up Exchange. The MS Exchange Team explains the backup and restore operations in more detail in this blog post.
The MS Exchange Team has written a blog post answering the question of whether or not a 32-bit version of Exchange 2010 will be released.
Most people familiar with Exchange are aware that Exchange Server 2007 was the first version that required 64-bit hardware and operating system to run. A 32-bit evaluation version was made available for testing, training, demos, and for running the management tools on 32-bit operating systems. This was satisfactory for most people who still ran 32-bit hardware on their administrative machines and lab servers (labs often being made up of older ex-production hardware). I myself still run a 32-bit Exchange 2007 organisation in VMWare for everything from training to taking screenshots for blog posts.
Fast forward to 2009 and 64-bit hardware is far more mainstream and affordable (I spent less than $500 on a 64-bit capable system with plenty of disk and RAM about 6 months ago). As a result Microsoft will not release a 32-bit version of Exchange 2010, requiring 64-bit hardware and operating systems for all server roles and administration tools with the single exception of remote PowerShell sessions (ie remote command line). Or, in their own words:
We are not shipping a 32-bit evaluation version of Exchange Server 2010.
More detail is available at the MS Exchange Team blog. The blog post explains in more detail what the implications are for the following common scenarios:
Data Import/Export (yes, you will need 64-bit Windows and 64-bit Office 2010 to perform import/export operations)
On the bright side, it is a good justification for any Exchange engineers out there who want their employer to buy them a new laptop.
New UM Administrator, UM Recipient Administrator, and UM Prompt Administrator roles so that UM management can be delegated properly.
“Red lamp” or Message Wait Indicator (MWI) support. This was a show stopper for some UM deployments with our own customers so its good to see support is now included. Although as the UM guys note, the majority of people check their inbox before they check their voicemail so the MWI issue turned out to be far less critical than many thought.
Voice to text transcripts for voicemails (claiming about 75% accuracy). Handy for previewing voicemails, checking voicemail in crowded/noisy locations, or as I noted recently this is potentially a huge benefit for the hearing impaired.
Friends, as a part of Microsoft’s second round of restructuring, my position was eliminated yesterday and my employment with Microsoft has ended. While there were many rewards that came from my job, the most satisfying element was knowing that our time spent together helped improve everyone—whether at conferences or through this blog, I’ve learned as much from you as you’ve learned from me. Sharing information, debating positions, and doing the right work for the right reasons are all very important and I’m honored and humbled to have been trusted by so many of you.
If you’ve attended a security session at TechEd in the last few years then chances are you’ve seen one of Steve’s incredibly engaging presentations. I myself was quite amazed at not only the depth of understanding he exhibited in such a wide range of subjects, but also the entertaining way in which he delivered the material to an audience. Security can be a dull, unexciting topic at times, often pushed into the “too hard” basket. I think Steve did a fantastic job keeping it interesting and at the forefront of people’s minds for such a long time.
As with earlier versions of Exchange Server when you first install Exchange Server 2010 it configures the first mailbox database for you. In Exchange Server 2007 this database was placed in a Storage Group called “First Storage Group” and was simply named “Mailbox Database”.
This was not a problem in earlier versions of Exchange. Databases were always named relative to the server they were hosted on and the storage group they were contained within, so a database named “Mailbox Database” on SERVER01 had a unique name such as “SERVER01First Storage GroupMailbox Database” which would not conflict with another database named “SERVER01Second Storage GroupMailbox Database”, even though they are both named “Mailbox Database”.
When you look at the first mailbox database on your Exchange Server 2010 server you’ll notice the naming is different. Here is an example.
The first database name has a random number appended to it that is designed to be unique to that Exchange organisation. That seems strange until you consider it in the context of the new Exchange Server 2010 database concepts. Here it is explained by Paul Robichaux:
Here’s the deal: in Exchange 2007 and earlier, mailbox and public folder databases are children of server objects. That means that you can uniquely identify a database by a combination of its name (which may not be unique throughout the forest) and its server name (which is guaranteed by AD to be unique). In Exchange 2010, the database is no longer “owned” by a particular server. Instead, it’s a member of a DAG, and it may actually become active on any server in the DAG at any time. That means that your database names shouldn’t include the name of the server. DAGs can span AD sites, too, so guess what: don’t use the AD site name (or the name of the physical datacenter) either. Otherwise the name of the database may not correspond in any way to where the database is actually active.
A few months ago I wrote an Exchange Server 2007 transition guide and uploaded it here to this blog. I titled it “Exchange Server 2007 Turbo Transition” and it contains 40 pages of step by step guidance for a simple single-server transition from Exchange Server 2003 to Exchange Server 2007.
I didn’t announce it at the time in a blog post, I just wrote a page for it and added a link in the sidebar to promote it. It is a free download, no registration or anything else required to grab it. I’m pleased to see that it has clocked up over 300 downloads since I released it in February.
With the release of Exchange Server 2010 Beta I’m already starting to work on new material to release here. I’m considering a few scenarios to cover:
Transition from Exchange Server 2003 to Exchange Server 2010
Transition from Exchange Server 2007 to Exchange Server 2010
Separate in-depth guides on deeper concepts such as Exchange Server 2010 anti-spam, high availability, archiving, disaster recovery etc.
This is where I need your feedback. If you have read Exchange Server 2007 Turbo Transition and have any comments or feedback about the content, the level of detail, the writing style, or anything else, then I’d love to hear from you so I can start shaping the next series of guides for the right audience. Drop a comment here or head over to my contact page to submit your feedback.