Fortified with E12

Now to the 64-bit-only issue, which has an immediate and profound effect on your upgrade path. It will no longer be possible to take the tried-and-tested route of stuffing a CD into your server late on Friday afternoon, running the setup program and having everything done before you disappear to the pub. Frankly, I’m delighted, since I’ve far too often had to pick up the pieces of the disasters caused by people doing exactly that (almost always without taking appropriate backups first). They almost always wear a rather sheepish look that implies that if Microsoft allows you to do something then it must be alright – well, Microsoft also allows you to reformat your hard disk, but I wouldn’t recommend that as the first step of your upgrade cycle either. The reason I can so confidently condemn this disastrous upgrade technique is that I’ve done it myself on my own servers in the past and spent most of the night fixing the mess. Naturally, this has always happened the night before I have to rise at 5am to go to the airport to fly somewhere, which takes the concept of looming deadline to new levels of panic. Nowadays, I know better.

Fortified with E12

So you’ll need a new 64-bit server and a brand-new installation of E12. Of course, if your server forms part of an existing Active Directory domain, the new E12 install will know all about your existing Exchange Server and will automatically join itself to the existing Exchange Server namespace. To be honest, this has always been my preferred route for upgrading the hardware underlying an Exchange Server installation, but now it is, in effect, mandatory. What it does mean is that you’ll have to do a lot of planning first, and thinking about how to get the new server into the rack is the very least of your problems.

You see, all the old definitions of what Exchange Server does become redundant in this new E12 release. In the past, all you needed to know was whether the server software was the Standard Edition or Enterprise Edition (and hence, clusterable) and whether you were going to split the functional roles into separate front ends and back ends. This type of architecture allowed you to have front-end servers to handle all the user traffic, while the mailboxes and other databases were stored on back-end servers. The topology was especially important for large networks to even out the loads. With E12, all this changes. Now you need to think far more carefully about the roles you assign to each particular server, as they can take on one or more of five clearly defined new roles: Bridgehead server; Client Access server; Gateway server; Mailbox server or Unified Messaging server.

A Bridgehead server routes emails around your organisation, normally between different sites, and E12 lets you have multiples of them. They’ll manage themselves automatically to offer the least number of hops between your organisation sites, and they’re fault-tolerant too, so one can take over the load of another automatically. A Gateway server sits at the perimeter of your network and handles all the internet traffic in and out of the organisation. It does all the message cleaning, anti-spam filtering, checking of addresses and so forth, and then routes the messages to the nearest Bridgehead server. A Mailbox server hosts the mailbox databases and/or public folders themselves. This is going to be the server role that consumes lots of disk space and memory, for handling all the email flow to and from disk storage. A Client Access server is one that allows users to connect via Outlook Web Access, Exchange ActiveSync, POP3 and IMAP4 protocols. This is the role that you used to call the front end, but now it’s much more flexible in its deployment than that term implies.

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.

Todays Highlights
How to See Google Search History
how to download photos from google photos