Tips on installing Exchange 2007 in to an Existing Exchange Organisation – Part 1…

by Andy Grogan on December 3, 2008 · 0 comments

in Exchange 2007 (General), Exchange 2007 (Installation), Exchange 2007 (Migration), VMWare

I have been spending a lot of time with Exchange 2007 lately (my wife is getting jealous) where I have been working on the co-existence scenario that many of us will face (or perhaps are facing and have faced) for and during our migrations. In this article I would like to share with you some of my findings and what I have found to be (personally) the easiest way to get Exchange 2007 into your 2003 organisation with the least hassle – and what you can expect to happen when it is installed there (for those of you whom have not taken the plunge just yet).

Before we begin along this road I feel that it is relevant to suggest (and point out) the following (even though they maybe obvious):

  • Exchange 2007 is a beast and when installed along side an existing Exchange installation makes some fundamental changes (not just to Active Directory but to your Exchange 2003 configuration) – please ensure that you have FULL and verifiable backups of the following BEFORE you begin -
    • All domain controllers that make up your domain (if you have parent and child domains – back the DC’s up here as well)
    • All Exchange 2003 servers in your domain – these backups should include the Databases, Transaction Logs, System States (which in the case of clusters should be BOTH nodes) meta-bases (I know that this sounds like overkill – but when embarking on such a process you need to give yourself the best “get out” as possible – backup your Front End servers as well.
  • I am working in a test lab – where I have tried to get the configuration as close to one of my production domains as possible – it is impossible for me to test out EVERY possible scenario and configuration – be aware that there might be specifics to your install that could mean that you need to deviate from suggestions that I make here – in a nutshell if anything goes wrong, please do not blame me.

Overview of my initial Exchange 2003 configuration:

My initial configuration is as follows:

  • Single Windows 2003 x64 SP2 domain controller
  • x 1 Exchange 2003 SP2 (all latest fixes installed) – Front End Server
  • x 1 Exchange 2003 SP2 (all latest fixes installed) – Clustered Exchange Instance (x 2 Nodes Active Passive)
  • 1200 Mailboxes balanced across 3 storage groups on the cluster (Default SG + Database, General Users SG + Database, VIP Users SG + Database)
  • An Organisation called “LAB” working in native mode (no pre Exchange 2000 Servers)
  • A Single Administrative Group (entitled the default “First Administrative Group”)
  • A Single Routing Group Connector entitled “Send_to_Internal” – this allows for the test domain to send messages to my production Exchange environment.
  • A set of public folders with two folder entries and a total of 14 items (of varying sizes)

The following are some screen shots of the configuration within the lab.

The following screen shot is a view of the Exchange 2003 servers within Active Directory Users and computers which make up my initial Exchange environment that I wish to migrate to an Exchange 2007 CCR environment – you will see a MSDTC resource (required for the installation and updates of Exchange 2003 clusters), a virtual Exchange server (LAB-EX-01), a pair of clusters nodes (x32EX-ND01 and 02) and a 2003 Front End Server (x32–FES01)

aduc1

The following is an expanded view of the Exchange system manager within my 2003 organisation prior to the installation of Exchange 2007 – here you can see my clustered EVS along with my three storage groups – please note the Public Folders database – this is important for reasons that I will explain later.

aduc3

So a general overview of the LAB system that I have in place would look like the following:

exsystem

Objectives of the install in my lab:

I am one of these people whom on the surface may seem retentive (as I like to establish objectives for any task that I do) I feel that it is important to derive a set of goals that need to be achieved. This exercise is not different therefore the following is what I proposed to myself needed to be gained at the end of this task:

  • To represent a scaled down version of my Exchange 2003 organisation – retaining the key elements that would be affected by a production migration to Exchange 2007
  • To install the Exchange 2007 schema extensions, along with the Legacy Components into my 2003 organisation without issues – and report on any issues that occur
  • Install all required Exchange 2007 roles into my LAB without issues – report on the problems that I came across
  • Successfully move 1 user to the CCR cluster and prove that mail can be sent between the Exchange 2003 and 2007 servers
  • Ensure that the following features are still working for users on both the Exchange 2003 and 2007 servers:
    • OWA
    • MAPI Access
    • Public Folders

Now, the above list does NOT represent all of the objectives that I would wish to complete during a live migration – you need to remember that at this stage I am taking things a few steps at a time. What I would like to do over the next few weeks to go through an entire sequence of migration using this lab to the point where I de-commission the 2003 Front End and the 2003 Cluster – however this article is based around correctly getting Exchange 2007’s foot in the door of my (and perhaps your) environment.

Installing Exchange 2007 into a 2003 Organisation:

Ok, before I get down to the “nitty gritty” I thought that I would just say a few words on “Interoperability” or more commonly “co-existence” mode (essentially Exchange 2007 working along side Exchange 2003).

Exchange 2007 is designed so that it can be installed into an Active Directory forest which contains either Exchange 2000, Exchange 2003, or Exchange 2003 and Exchange 2000 – you should note here that Exchange 5.5 co-existence is not supported.

So in a nut shell if you install Exchange server into an organisation that contains any version of Exchange above 5.5 then you are in “co-existence” mode.

For Exchange to be installed into an Organisation that has either 2000 or 2003 (or both) installed the following situations MUST be true:

  • The organisation needs to be running in native mode (e.g. no server prior to Exchange 2000) this means that:
    • There should be NO instances of 5.5.
    • No instances of the Site Replication Service (SRS)
    • All ADC’s (Active Directory Connectors) have been removed and un-installed

I will be discussing specific issues in regard to Exchange 2007 roles and indeed changes that the installation makes to your Exchange 2003 organisation a little later on in this article, however I would to focus on the installation process that I went through and comment on issues that are of note as an when I met them.

Installation Step 1 (Preparatory work):

If you have a long standing Exchange 2003 organisation there is a fair chance that there have been some customisations along the way which you may have forgotten or indeed if you have inherited the installation you may not know about.

In order to minimise issues during the installation I recommend the following (ok, I don’ just recommend I really think that you MUST follow these procedures) – I have looked at things in that past which have prerequisites and thought “of what the hell” and then gotten bitten on the bum – integrating Exchange 2007 into your 2003 organisation is not a “bespoke” task and should be treated with the highest level of care – so the more you have done to review your existing installation the better placed you will be should issues occur:

  • Download the Exchange Server “Best Practices Analyser” from http://www.exbpa.com and install it onto an machine in your Organisation. When you have installed the tool, you will need to run through the following steps:

From the Windows Start Menu go to “Programs->Microsoft Exchange->Best Practices Analyser Tool” which will display the following screen:

bpa1

You have the option of either cancelling the check or letting it take its course, in either respect the following screen will be displayed (unless you have not downloaded the latest version – in which case you might need to download some updates):

bpa2

When the above screen is displayed – click on the “Select options for a new scan” – which will display the following screen:

bpa3

Enter in the name of your domain controller (this assumes that the account that are logged on with has the correct permissions to access both Exchange and AD) and then click on the “Connect to the Active Directory server” which will then display the following screen:

bpa4

Enter in a name for you scan – select all nodes of you organisation from the “Select the scope for this scan” and then ENSURE that you have selected the “Exchange 2007 Readiness Check” – choose the speed of you connection and then click on the “Start scanning” option.

After a brief pause you will be presented with something similar to the following screen:

bpa5

Click on the “View a report of this Best Practices scan” – which will reveal something similar to the following (please note that you may have issues that need to be addressed on your report).

bpa6

If you have critical issues highlighted the you MUST deal with them prior to embarking on the installation of Exchange 2007 – it would also be a good idea to address the Warning issues prior to installation just in case.

After you have addressed the issues with the Readiness Report – you MUST run the BPA again – but this time around when you get to the New Practice Scan screen – select “Health Check” from the “Select the scope for this scan” options – follow the wizard through and correct all Critical and warning issues.

  • Gather as much information as possible about your existing Exchange installation:

EXCHDUMP is an excellent tool for reporting on the configuration of your Exchange organisation – you can use it to document your Exchange installation at a very low level. Should any issues occur during the installation of Exchange 2007 you can refer to the EXCHDUMP report to help you recover.

You can download the EXCHDUMP tool from here: http://www.microsoft.com/downloads/details.aspx?familyid=d88b807d-964e-4bf8-9344-754892e9f637&displaylang=en – extract it to a folder on your Exchange Server and then run it using the following command syntax:

EXCHDUMP /server: /exorg

So for example if I had an Exchange server called “AJG-EX1” the command syntax would be:

EXCHDUMP /server:ajg-ex1 /exorg

The output for which, when typed into a command window looks like the following:

dmp1

This will produce a detailed HTM file in the folder where EXCHDUMP containing your configuration data (if you have more than one Exchange server you will need to repeat the command for each Exchange server) – when you have complied this store the output HTM and XML files in a safe place.

Installation Step 2 (Preparing AD and Your Exchange 2003 Organisation for Exchange 2007):

Now you have a couple of options here which apply to two scenarios:

You can then run the following command to get the environment ready:

:\Setup.com /PrepareAD -or– :\Setup.com /P

The above command will complete the following actions:

    • /prepareLegacyExchangePermissions – required to ensure that the Exchange 2003 Recipient Update Service works correctly
    • import the schema (/prepareSchema)
    • Create the required Exchange Universal Groups
    • place the Exchange Configuration in AD
    • run the /prepareDomain task
  • If you have a x64 server in your organisation which is ear marked to become the first Exchange 2007 instance you can use the x64 bit Edition of Exchange to completed the required changes as per above without having to install the 32bit Edition.

The point of the above is that you can use the “Trial” x32bit Edition of Exchange 2007 to prepare your domain for Exchange 2007 as well as using the x64 version of Exchange – this gives you the flexibility to prepare and wait (using the x32 Edition) should you not have any Exchange 2007 servers present, or, go for the whole “kit and caboodle” should you have an existing x64 server.

Tips when preparing you domain:

  • Take backups of your DC’s before you begin (please)
  • Ensure that the schema master is online and all other FSMO role holders are online and functional
  • Disable any file level Anti-Virus checkers either on the server where you are running the commands from -or– the FSMO role holders (especially the schema master) – re-enabled them when you are finished

Installation Step 3 (Installing your first x64 Exchange 2007 server):

Now, for the purposes of this I am going to assume that most of you are fluent in install Windows 2003 x64 on a server – therefore I will not be covering this here.

This article centres around me installing a CCR cluster into my Exchange 2003 environment (although I will be making general recommendations) but for those of you whom are looking for a step by step guide to creating a CCR cluster you will find detailed steps here:

here: http://telnetport25.wordpress.com/2007/08/27/test-lab-virtualisation-of-exchange-2007-ccr-cluster-using-vmware-part-1/

here: http://telnetport25.wordpress.com/2007/08/28/test-lab-virtualisation-of-exchange-2007-ccr-cluster-using-vmware-part-2/

here: http://telnetport25.wordpress.com/2007/08/29/test-lab-virtualisation-of-exchange-2007-ccr-clustering-using-vmware-part-3/

and here: http://telnetport25.wordpress.com/2007/09/02/test-lab-virtualisation-of-exchange-2007-ccr-clustering-using-vmware-part-4/

What I would like to discuss here is making sure that your x64bit Exchange servers are ready for the installation from a prerequisite point of view – the following document (PDF format) contains a chart which details the required configuration on your x64 server prior to installing Exchange 2007:

adobePre-RecGuideExchange2007.pdf

Now assuming that you have performed that Forest / Domain preparation and your existing Exchange 2003 environment is still working, and you now have a freshly built Windows 2003 x64 server (in my case the first node in my CCR cluster) you can begin the Exchange 2007 install.

Now, above I have published 4 articles which deal with installing a Exchange 2007 CCR cluster – these can also be applied when installing CCR into your Exchange 2003 environment.

Now Microsoft states that the first Exchange 2007 role into your Exchange 2003 Environment should be a CAS (Client Access Server) role (shortly followed by a Hub Transport) then other roles.

All of which is good advice (as without a CAS server you will not be able to connect to any mailboxes on the new Exchange 2007 Database server, nor will e-mail route between the 2003 servers and the 2007 databases servers) – however it does not hurt anything if the first 2007 server you install into your Exchange 2003 environment is a database server (or in my case a CCR) – it will just mean that no mailboxes will be accessible nor will mail route to them until the other roles are installed and configured.

Now, the first thing you may be asking is – if I don’t have a Hub Transport server, where have I placed the FSW role for my CCR cluster – well this is where you find out a couple of interesting things:

  • The FSW (File Share Witness) although it is essential for avoiding “Deadlock” scenarios under MNS clustering (this is the situation where the cluster service does not know which node to fail the services onto when there is a minority of the nodes in the MNS set left) – you can install the cluster service and Exchange 2007 without the MNS share being present (although you should create it quickly)
  • Most people know this, but, the FSW does not have to be on a Hub Transport it can be installed on any server which is a member of your domain – so in my case as I didn’t have a HT role installed at the time I built the CCR cluster – I used my domain controller.

Now the reason why Microsoft advises that you install the FSW on the HT is so Exchange can maintain control over its clustering (without having dependencies on servers external to the Exchange configuration) – and – generally speaking there should be a HT per site where a CCR is installed (if you only have a HT in your primary site where the primary node is, and the primary site goes down – then when the passive node takes over at the secondary site there will be no HT present to route messages).

So when looking back at my scenario I need to move the FSW to the HT role as the HT becomes available – the question is – how do you move the File Share Witness to a Hub Transport Role?

Well the following is a sequence that I have found works correctly:

  • Log onto the Active Node of your CCR cluster and open up the Exchange Management Shell

When the shell has loaded type in the following management command: stop-clusteredMailboxServer -identity -StopReason “”

So in the example of my lab I used the following syntax:

cm1

This command will close down the CCR cluster gracefully and ensure that any of the work that we are doing does not damage the cluster.

  • On you Hub Transport Server – create a new folder called “FSW” and Share it out, you will need to assign the following SHARE (not NTFS) permissions:
    • Clustering Account (which the CCR cluster service runs under) Allow [Full Control, Change, Read]
    • Everybody Domain Group allow [Read]

Below is an example of this process being performed for SHARE permissions:

cm2

When you are happy with the Share permissions click on “Apply” and then “OK” and on the “Security” tab of the FSW Properties.

This will display the security properties of the folder – here click on the “Advanced” button and the “Advanced Security Settings for FSW” will appear:

cm3

From this dialog box – un-tick the “Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here” tick box which will then prompt you with the following:

cm4

Click on the “Remove” button and then click on “OK” to be returned to the Security Dialog box:

cm5

Here add in the account which the CCR cluster uses as its service account and assign it full control – it is also an idea to add in the local administrators group on the HT server to have full control as well.

Now that we are happy that we have our new FSW share, under best practices we should now configure a CNAME entry for it in Active Directory DNS.

By establishing a Global CNAME DNS record for the HT server which contains the File Share Witness we alleviate the having to reconfigure the cluster should we lose that HT server – in the event of a failure all we need to do is create a FSW share on another server with the correct permissions and then change the Host for the CNAME in DNS (rather than having the reconfigure the cluster service).

Below is a short video on how to configure a CNAME in DNS as always with my Videos you will need WinRAR or 7–ZIP to extract them:

vidicoCreateCNAME.rar [229KB – Compressed – [12.9 MB – Expanded]

For reference I called the CNAME “FSWCCR” in my domain.

Ok, now that we have our new Share on our Hub Transport AND we have setup a CNAME record for the FSW all we need to do now is reconfigure the cluster services.

Therefore here you need to jump onto the Active Node of your CCR cluster (remember that we have taken the Exchange Services offline) – open a Windows command prompt (CMD) and type in the following command:

cluster.exe res “Majority Node Set” /priv MNSFileShare=\\ – so in my case the command looked like the following:

cm8

Hit enter and your are ready to go – right – actually no, when I did this in my test lab I received the following error message:

cm9

I looked at the error, scratched my head, and thought “no it does not”. I did a little research and found that this error message is caused by strict name checking being enabled on the HT server where we have located the FSW to – so to get around the problem you will need to jump onto the HT server and open up REGEDIT.

In REGEDIT navigate the the following Key:

HKLM\SYSTEM\CurrentControlSet\Services\Lanmanserver\parameters

Add in a REG_DWORD key called “DisableStrictNameChecking” and give it a value of 1 – see the following example:

cm10

When you are happy with the configuration above – restart your HT machine.

When the HT has restarted go back to the primary node of your CCR cluster and re-run the command that previously failed:

cm11

This time (hopefully) you will receive the above message – now all you need to do is activate the changes by typing in the following command:

cm12

Remember in the EMS to type the following command: start-clusteredMailboxServer -identity when the cluster group has moved – this will bring your Database server back online.

Summary:

Ok, I have gone on and on in this article, and I have jumped about a little bit, so I am going to call it a day here.

Looking back I am confident to say that we have gone through the following in this article:

  • Steps to take when backing up your Exchange 2003 Organisation when preparing for Exchange 2007
  • Gathering Data about your Organisation, and ensuring that it is ready for 2007
  • Establishing a pre-requisite guide for you server hardware
  • Taking the initial installation steps of you first Exchange server
  • Clarifying some issues about which roles can be installed first
  • How to move the FSW if you didn’t place it on a HT due to one not being available

In part 2 I would like to cover:

  • Changes that adding a HT makes to your Exchange 2003 organisation, specifically routing
  • Why Mail might not seem to work after the HT is installed
  • Clarifying Legacy Public Folders and how it all works with Exchange 2007 CCR

{ 0 comments… add one now }

Leave a Comment

*

Previous post:

Next post: