Wow, I guess I got a little carried away in my last post about this – so I am going to try not to jump around so much this time around. Its hard not to get excited about Exchange 2007 as it presents so many new opportunities to accomplish tasks, and from my perspective so much more to learn.

In this part of the process I would like to cover the following items:

• 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

However before I get going I would like to cover some of the characteristics that your Exchange 2003 organisation will take on when operating in Exchange 2007 interoperability mode and cover some “Do’s and Don’ts”.

What happens when Exchange 2007 is installed into an Existing 2003 infrastructure:

When you install an Exchange 2007 server into an existing Exchange 2003 organisation you will see that a new Administrative Group entitled “Exchange Administrative Group (FYDIBOHF23SPDLT)” – you will also notice that within this administrative group there is a single routing group entitled “Exchange Routing Group (DWBGZMFD01QNBJR)” where all Exchange 2007 become members. It is important that you understand that you MUST NOT make any modifications to either the Administrative Group or the Routing group (e.g. delete items, rename or move) this can and most probably will have serious consequences for your Exchange Organisation.

Just so you know, although many will have already worked out, the purpose of the Routing Group that the Hub Transport installation creates in your Organisation is to route mail between your Exchange 2003 servers and 2007 Database servers.

It is also worthy of note that Exchange 2003 and 2007 server are not supported in the same routing group – so please don’t try move one into the other.

Below is an example of what my LAB environment looks like from the Exchange System manager:

Tip:

Now one key thing that you should notice above is that my CCR cluster server (EX-CCR-01) is the Routing Group Master. Now the reason for this I suspect is because I installed the CCR cluster into the Exchange 2003 organisation before the Hub Transport (Microsoft recommends installing the CAS and HT roles prior to the mailbox role). I have not seen any undesirable effects caused by this, however, just in case I set the routing group master to be my Hub Transport Server when I installed it (this makes sense as a CCR cluster plays no part in message routing as it only accommodates the Mailbox role).

Management:

The following table describes management options for your Exchange servers when operating in interoperability mode:

Action	Exchange System Manager	Exchange Management Console	Exchange Management Shell
Manage Exchange 2007 Server Roles	No	Yes	Yes
Manage Exchange 2007 Mailboxes and Recipients	No	Yes	Yes
Manage Exchange 2000 / 2003 Specific Features (IMF, Active Sync, OWA,SMTP, 2000 – 2003 routing groups)	Yes	No	No
Manage Exchange 2000 / 2003 Servers	Yes	No	No
Manage Exchange 2003 Mailboxes and Recipients	Yes (including ADUC)	Yes	Yes

You can download a copy of the above table from here:

Exchange Management.pdf

Installation of the HUB transport role:

These articles generally assume that you have installed Exchange 2007 a couple of times, however, it is important to note that the installation of the Hub Transport role into a mixed organisation is slightly different.

Just after you have selected the Hub Transport role, you will be asked to configure the mail flow settings (essentially Exchange 2007 setup knows that it is being installed into a mixed Organisation, and wishes to setup a routing from connector that will allow for mail to flow between the Exchange 2007 servers and the Exchange 2003 servers.

During setup you will be prompted with the following options dialog box:

By clicking on the “Browse” button you will be presented with the following screen (your may look a little different):

From here it is recommended that you choose the Exchange 2003 Routing Group Master – which in my case was LAB-EX-01, and then click on the “OK” button, this will return you to the main setup screen where you can click on the “Next” button. Exchange 2007 will now go away and install the Hub Transport role and configured the required connections so your server can communicate.

Ok, I installed the role everything seems fine, but I cannot send or receive any mail to mailboxes on the Exchange 2007 Server:

I have had this a few times, and it is pretty much always down to a principle called “Back Pressure”.

“Back Pressure” is a monitoring feature which is included on both the Hub Transport and the Edge Transport server roles. The purpose of this feature is to monitor the following system resources:

• Free space on the disks where the message queue databases are stored
• Free space on the disks where the message queue Transaction logs are stored
• Amount of uncommitted messages transactions stored in RAM
• Memory used by the Transport processes
• Memory used by all processes

The following are pressure points applied to each of the above monitored scenarios:

• Normal: Processes are not stressed and message flow and connections are accepted
• Medium: The processes are under slight pressure – Back Pressure is applied so that Messages from the Organisations domain can flow, however the server will reject new connections and messages from external sources until the situation is resolved
• High: The processes are under severe stress – Full Backup Pressure will be applied – this means that all mail flow stops and the server will not accept any connections or messages.

Again on this occasion I experienced back pressure – caused by the default location that Exchange 2007 places the transport queues in [C:\Program Files\Microsoft\ExchangeServer\TransportRoles\data\Queue]

Being a test lab I had not specified a large partition for the system drive – just enough for the OS and the Exchange binaries therefore the Transport Databases (apart from also being the worst place in the world to be placed) triggered a “High Back Pressure” scenario.

In order to gain this information I had two clues;

• No mail was flowing
• When checking the application event log I saw a number of events which looked like the following:

In order to get around this issue, I created a dedicated (6GB) partition on the server for the Transport Database and completed the following steps:

• On the new partition created a directory called “Queues”
• Within the Queues Directory I created two other folders called “DB” and “Logs”
• Opened the following file in Notepad [c:\program files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config]
• The navigated to the following lines in the file and gave them the respective values to reflect the partition and directory I created above:
  • QueueDatabasePath Value =”T:\Exchange\Queue”
  • QueueDatabasePath Value = “T:\Exchange\Queue”

Below is an example of the the file in question looks like, you will note that it is similar in structure to an XML file – which means that if you have an XML editor handy editing this file is much easier:

 

Upon entering my changes into the file I restarted the “Microsoft Exchange Transport Service” on my Hub Transport.

This will then move the existing Transport databases and logs to their new location and (hopefully) allow for mail to flow.

Public Folders and CCR:

From my perspective this has been perhaps one of the more complicated things to get a straight answer on the following is a run down of how to work with Public Folders in a CCR environment.

Scenario – You have an existing Exchange 2003 Organisation where over the years your user populous has grown used to the functionality of Public Folders. Now you know that support for Public Folders is being diminished within Exchange, however you are in no position to perform a migration from Exchange 2003 to Exchange 2007 and get rid of Public Folders.

Right if you read the deployment guides for Exchange 2007 they will (generally) recommend that when installing Exchange 2007 into a Exchange 2003 organisation they suggest that the CAS the HT roles should go in first (sensible advice).

If you then read a little further about CCR clustering for example this excellent article on TechNet about Planning for CCR: http://technet.microsoft.com/en-gb/library/bb123996.aspx towards the bottom you will see an entry which is entitled “Cluster Continuous Replication and Public Folder Databases” cutting to the “nitty gritty” the following are the recommendations for Public Folders in CCR environments:

• If you have a single mailbox server in your Organisation and it is a CCR cluster, it can host a public folder database – in this configuration Public Folder replication is disabled (this will probably not be the case in Interoperability situations – like ours)
• If you have more than one mailbox server in your organisation but, only the need to a single Public Folder database – then this can also be located on the CCR cluster and Public Folder replication will again be disabled. (Again it is unlikely that this would apply to us whom are moving from Exchange 2003 to Exchange 2007)
• If you have existing Public Folder data that you wish to reside on a CCR cluster, you can use Public Folder replication between the legacy PF database and the PF database that resides on your CCR cluster – this should be done as quickly as possible, and when completed the legacy Public Folders stores should be removed from your Organisation and no others should be added. (this is potentially our situation)

The key point to remember here is that if you have existing Public Folders in your Exchange 2003 organisation and then you move to interoperability mode by installing Exchange 2007 with a CCR cluster you need to get the Public Folders from the 2003 servers migrated over to the CCR Public folder database as soon as possible – and then remove the 2003 Public Folder trees.

During the times that more than one Public Folder database exists in and Exchange organisation where a CCR cluster is present (typically migration scenarios like ours) it is important to understand the difference between the following terms:

• “Lossless” Outages
• “Lossy” Outages

Lossless Outages:

This is typically when the System Administrator takes down the services on the Primary CCR Node and moves them to the Secondary Node for maintenance purposes (typically this will be done using the move-clusteredMailboxServer cmdlet) – under these circumstances the Public Folder database on the CCR cluster should come back online and replication will continue to work (even if there are other Public Folder Databases within the organisation).

Lossy Outages:

These occur as a result of a failure on the Primary Node (there can be loads of reasons) but the key characteristic you will see is that if you have other Public Folders in hosted in your Organisation, when the CCR instances fails over to the Secondary node – the storage group for the Public Folder Database will not come online (whilst Public Folder replication is enabled). In this case you will need to get the original node back online to ensure the database will come back. (This happens if replication data has been lost by the outage, and thusly is contained in the Transaction logs on the primary node which are now not available).  

I hope that you have enjoyed this article and find some of the concepts useful – no doubt as we continue there will be more and more to post back with in regard to our migrations.