Let’s be honest – Exchange 2007 is a beast of a product, and indeed potentially a bigger leap in redesign than the jump from Exchange 5.5 to 2000. From a management perspective it has forced many Exchange Administrators to rethink their administration policies and learn new technologies which prior to Exchange 2007 they would perhaps not considered being part of their skills arsenal.

For example; In Exchange versions 2000 to 2003 – Exchange admins did not necessarily need to be a scripting guru in order to do his/her job. However in Exchange 2007 the integration of the Exchange Management Shell (based upon Powershell) and the amount of configuration options that the Management Shell controls which are not in the Exchange Management Console an Exchange administrator needs to develop at the very least, an understanding of basic scripting techniques – even if this is at the single command level.

In the case of Exchange admins whom run larger Exchange 2007 installations (or indeed consultants and architects) the skill with the Management Shell need to be “ramped up” in order for them to achieve their deployment goals – and indeed get the very best out of the product – this can (in some cases not all) move Exchange Admins out of a “comfort zone” and into a world where they are almost part Exchange Systems Admin and part developer (a hybrid).

Of course the changes are not just limited to mere scripting – the major Architectural changes that Exchange 2007 has brought with in – for example the move to x64 Hardware being the only supported production platform.

In previous migrations between Exchange versions we were all safe in the knowledge that we had the option of “in place” upgrades on the same hardware (if it was up to the job) – in many cases now companies are in the position of having to purchase new hardware to meet or indeed supplement the the demands of Exchange 2007.

Closely linked with the above is the inception of “Exchange Server Roles“.

Roles are not only just a big conceptual change, but have a significant impact on the specification of your Hardware and topological layout. People whom are embarking upon a migration path to Exchange 2007 need to work through the processes of sizing (specifying their hardware according to the role that it will be performing – examples of good sizing articles on the Web are:

If you spend time looking through the above you will see that there is a significant increase in the amount of work that is required to correctly size your Exchange installation – there are of course other choices that need to be made – for example:

  • Do you cluster?
  • If you cluster – which clustering technology do you use (CCR, SCC?)
  • If you are not using clustering do you place all the compatible roles on a single server?
  • If you wish to split the roles out do you choose to have dedicated mailbox servers with HT and CAS running on another server?
  • Do you use the Edge Transport Role?

All of the above can (and should) take weeks – perhaps months to correctly ascertain – and remember all of this is before you even place the DVD in the drive.

At this stage you might be tempted to overlook the sizing requirements of Exchange 2007 in favour of taking a “Best Guess” – however I urge you not to, Although the sizing calculators and advice look intimidating your should not underestimate the revised Disk I/O and Memory requirements for Exchange – these tools and articles are there to ensure that you do not run into issue later on down the line with the specifications that you have determined.

To add to the complexity of migrating to Exchange 2007 you also need to ensure that your existing Exchange and Active Directory environment  meets the recommended specifications and that you are ready for the added administrative overhead that occurs during the co-existence phase of your migration – it is worth reviewing the following articles before you install Exchange 2007 into your environment:

Exchange 2007 System Requirements

Planning for Co-Existence

Managing Exchange 2003 Settings in a Co-Existence Environment

By reviewing the above articles you will reduce the risk of problems during the Schema, Domain and Exchange setup processes however there are some other things that you should take into consideration before you begin:

  • If possible in your Organisation institute a “Lock Down” policy on Active Directory for the period of the Exchange installations – essentially ban any account modifications and directory structure modifications – this will make the process of a restore much simpler should you need to.
  • Take backups of ALL FSMO role holders BEFORE you begin the Schema / Domain preparation processes
  • If you are extra cautious and your schema master is a separate role holder from all the other domain controllers you can perform the Schema updates “offline” so to speak by either disabling replication via RepAdmin tool. This will prevent the changes from being sent to the other directory databases until you have verified that the Schema has been updated properly
  • You should disable local Anti Virus during any Exchange installation process
  • When installing the first Hub Transport into your environment it will create a routing group which ensures mail flow between Exchange 2003(2) and Exchange 2007 – you should take an Active Directory backup prior to the installation of the HT role – this will help you roll back should anything go wrong during the process (for example I had a support call where a person had not opted to create the Routing Group and then tried to manually create it – potentially it would have been quicker to restore from backup considering the amount of time that we spent troubleshooting it)

The above are just some of the many things that need to be considered on the road of the upgrading to Exchange 2007 – however to conclude this article the following are a number of other commonly overlooked or indeed misunderstood concepts when migrating:

  • Store Based Anti Virus Programs are not updated

    If your existing Exchange 2003 servers make use of VSAPI based checkers (for example McAfee Group Shield, GFI or Norton) you will almost certainly need to upgrade them for Exchange 2007 – this might represent additional costs for your migration if you do not have Framework licensing for your products.

  • Backup Tools and Agents

    Significant changes have been made to Exchange 2007 at the store level to allow for both streaming (being depreciated and not in Windows 2008) and VSS based backups. You should check that your existing backup product supports Exchange 2007 – and if you have installed Exchange on Windows 2008 you will need to upgrade your backup so that is knows that Streaming has been removed and VSS is the primary backup system.

  • Archival Products

    If you make use of a commercial Compliance product such as Enterprise Vault you will need to ensure that it supports Exchange 2007 – and also that any integration features (for example with OWA) are also fully supported.

  • Windows 2008

    Many people whom are embarking on Exchange 2007 SP 1 migrations will almost certainly be tempted to use Windows 2008 as their Operating System platform (and so they should) – however remember that Windows 2008 is a pretty large departure from Windows 2003 (certainly in terms of IIS and clustering). You should also consider any product that uses an Agent to communicate with Exchange (for example Enterprise Vault) is supported on the Operating System.
  • Depreciated Support for MAPI and CDO 1.2.1 and ASP Database based applications

    MAPI / CDO is no longer supplied as part of the default Exchange 2007 install – therefore you should note that if you have an application which resides on your Exchange servers which makes use of CDO it may cease to function – you can download the components from here:http://www.microsoft.com/downloads/details.aspx?FamilyID=E17E7F31-079A-43A9-BFF2-0A110307611E&displaylang=en.

    Additionally if you make use of a ASP based solution which communicates with a Database you need to know that it could experience issues on a x64 platform (you will need to check that there is x64 ODBC driver support).

  • Remember your Accounts Team

    For larger organisations it is possible that you have a dedicated accounts management team. Exchange 2007 re-adopted the Exchange 5.5 administrator model whereby accounts can be created in Active Directory Users and Computers – however the mailboxes need to be created via the Exchange Management Console or Indeed the Exchange management shell.

    Again like Exchange 5.5 from the Exchange 2007 Management tools you CAN create both the Active Directory account and the Mailbox – however if you need to add the user to groups and configure Terminal Services profile settings for example you will need to go back to ADUC to finish the job.

    What I recommend is that you get your Accounts People to work with the account in ADUC and then supply them with a Powershell script which will configure the mailbox settings as required – all they will then need is a copy of the Exchange Management Tools and Powershell on the machine with the required permissions.

  • Consider your permissions model

    Linked to the above you should give careful thought to the permissions and roles that you assign to people – there is a good article here which will provide you with help in making these choices: http://technet.microsoft.com/en-us/library/aa996881(EXCHG.80).aspx
  • SSL, the Client Access Server and the Auto Discover Service

    If you look at the Exchange server forums which litter the Internet you will find hundreds of posts which deal with the above. The AutoDiscover service is perhaps one of the most complex things to get to the bottom of (as it is linked very closely with correctly configuring SSL, the configuration of Outlook 2007 clients).

    Before you deploy users to your 2007 organisation ensure that you FULLY understand Auto Discover and SSL on CAS servers – the following are some very good links which will help:

    Whitepaper – Exchange 2007 Autodiscover Service
    Exchange Genie – Exchange 2007 Autodiscover Service Part 1

  • Exchange Analysis Tools

    If you make use of any Exchange Analysis or Monitoring tools (for exampleMailscape, OmniAnalyser, MOM 2005) ensure that they are compatible with Exchange 2007 – and upgrade them if they are not.

Well I think that I have rambled enough for this particular article – and I hope that it has given you some good pointers and food for thought before you embark upon your own personal migrations.