With the Microsoft Exchange Conference (MEC) just a month away, thoughts turn to the hot topics that will be discussed there. Of course, Exchange 2013 is the top order of business and Microsoft will dedicate the majority of their sessions to discussing the new server. Although I will pay attention to the Exchange 2013 sessions, I can think of three other interesting areas of debate that I’m sure will receive lots of attention.

The first is what changes have to be made to an existing environment to prepare for the deployment of Exchange 2013?  In this respect, we might consider the following:

• Choice of operating system: Windows 2008 R2 SP1 or Windows 2012? In either case, you’ll need new servers (or be able to repurpose some existing servers) because Exchange 2013 carries on the tradition established in Exchange 2007 of no in-place upgrades. Bare metal deployment is the order of the day. With a big focus on using PowerShell effectively, Windows 2012 offers some interesting automation possibilities that could be harnessed to make system administration easier, especially across multiple servers, and it’s likely to receive much of the attention as people focus on O/S choice.
• Choice of client: Outlook 2013 provides the necessary user interface for new features such as data leak protection and site mailboxes. There’s no word yet from Microsoft as to whether they will provide updates for older clients such as Outlook 2007 and Outlook 2010 to access these features; past experience indicates that we should prepare ourselves not to see an update unless (as happened with archive mailbox support for Outlook 2007), Microsoft receives substantial customer pushback about the need to support a certain feature. Outlook 2003 is now consigned to the wastebasket and is not supported by Exchange 2013. Exchange Web Services (EWS) based clients such as Outlook 2011 for Mac are.
• Support for older versions of Exchange: It’s unlikely that there will be many green-field deployments of Exchange 2013 and that the vast majority of deployments will be into existing Exchange organizations. Microsoft no longer supports Exchange 2003 so it, as well as any other servers running older versions, will have to be upgraded before you can deploy Exchange 2013. The exact details of the versions of Exchange 2007 and Exchange 2010 that support co-existence with Exchange 2013 are still unclear, but you’d imagine that updates will be necessary for the current Exchange 2007 SP3 and Exchange 2010 SP2 releases, if only to support the new Active Directory schema required by Exchange 2013.

The second is what support exists for add-on products that complement Exchange? Two categories come to mind:

• Software such as backup and archive products that need to be updated to support the new Exchange server model (only back-end mailboxes and front-end CAS boxes). Anti-virus and anti-spam products probably need some work as the Store has been overhauled and rewritten in managed code. Migration products (those that move mailboxes in a more automated fashion than the basic facilities provided in Exchange) are probably OK when dealing with mailboxes, but have a brand-new space to investigate to move “old” public folders to their new “modern” form. All products need to be tested against Exchange 2013 in a realistic environment to identify any gotchas.
• Given the new twist on Exchange’s architecture through the simplification of network connections by a focus on RPC-over-HTTPS, less of a need exists for the kind of complex CAS load balancing arrangements seen in large-scale Exchange 2007 and Exchange 2010 deployments. Load balancers became a fact of life because of the need to manage thousands of incoming client connections effectively and companies such as Kemp Technologies and F5 flourished as demand mounted for low-end and high-end load balancers respectively. That need for this kind of infrastructure is less obvious with Exchange 2013 and it will be interesting to see how these companies respond by finding new ways for their technology to add value.

I imagine that many MEC attendees will make a beeline towards software and hardware vendors who will be at MEC to establish what plans exist for their products to support Exchange 2013 and when new versions will be available for testing.

The last consideration is the most strategic and difficult. The introduction of any new software4 version brings the nasty “migration” word into play. For years, the migration question has been simple and largely boiled down to when the new software should be deployed. Now the question is whether the advent of Exchange 2013 marks the right time to change software strategy and move email into the cloud (either all-in or hybrid). I’m sure that there will be many who advocate that it’s better to do a one-time migration now and let a hosting partner take care of Exchange from this point on than to struggle with all of the trials and tribulations that migrating to Exchange 2013 will doubtless bring.

My MEC session (E14:307) is all about weighing up the advantages and disadvantages of moving email to the cloud, with Microsoft’s Office 365 service or to one of the many independent Exchange-based hosted offerings from other companies who can deliver better service and more flexibility than Microsoft’s one-size fits-all cloud service. It should be an interesting debate!

Follow Tony @12Knocksinna