Ok, in the previous part of this article I discussed how you can convert a clustered instance of Exchange into a basic instance (single server) – for part 1 have a look here: http://telnetport25.wordpress.com/2007/11/07/can-you-convert-an-exchange-2003-cluster-into-a-basic-non-clustered-installation-part-1/

In this part I would like to go through I restored the databases and transaction logs to the basic server instance, and then reconnected the databases.

Step 1 – Reconstruct your physical disk structure:

In the first part of this series I spoke about using EXCHDUMP to get a snap shot of the Exchange configuration on your cluster – in this step the data from EXCHDUMP will be essential.

As mentioned before you will have two files (one HTML and one XML) produced by EXCHDUMP which contain a description of your clustered Exchange environment – but we are more interested in the data that pertains to the physical disk structure.

If you open the HTML file and review the first section you will see entries that detail the disk configuration of your original Exchange Server (e.g. paths to DB’s and Transaction logs) – below is an example from my test lab:

With this information and if you are following this we need to recreate the Disk Folder structure described in the file for the Databases and the Transactions using the Exchange System Manager on my new Exchange Server; So for example:

On my original Exchange server I had a storage group called “SG-2–GEN” which had the following properties:

• Log File Path of: G:\EXCHSRVR\SG2–GEN\Logs\
• A Mailbox Database (both EDB and STM) path of G:\EXCHSRVR\SG2–GEN\DB\GEN-POP-DB.stm / or edb

Now the key things that I need are:

• A G: Drive
• A Folder Path on G: called G:\EXCHSRVR\LOGS
• A Folder Path on G: called G:\EXCHSRVR\DB

These can be manually created though Windows Explorer – however, care must be taken when creating the Storage Group and Databases in the ESM – as we do not wish to create a blank database or set of transactions logs – therefore when you have created the folder structure on the correct disk – in the Exchange System Manager you need to ensure that you follow the process below (for each storage group and database that has to be recreated – I cannot stress to you how important it is that you recreate them with the same names and the same paths that existed on the cluster):

Configuring the Storage Group:

In the Exchange System Manager navigate to “Administrative Groups -> First Administrative Group -> Servers -> ” – right click on the server and from the context menu that appears select “New” and then “Storage Group” – see below:

The New Storage Group properties dialog will be displayed – here you will need to name the Storage Group the same as it was on the cluster (which for my purposes would be SG-2–GEN) – you can refer to your EXCHDUMP data for information unique to you – see below:

Now – as you can see from the above – the locations of the Transaction Logs and the System Path are set to their defaults – it is ESSENTIAL that these are changed to the folder structure that you have created on your disk in the previous steps – therefore a properly configured storage group for me would look like the following:

When you are happy that the specifications of the storage group meets that of the original cluster – click on “OK”

Configuring the Database:

This is money maker – how we configure the databases – screwing up here is a pain in the backside!

Ok – Right click on the storage group that you have just created in the previous step and from the context menu that appears select “New” and then “Mailbox Store” – this will display the Mailbox store properties dialog which in the case of my environment should be configured on each tab like the following examples – you will need to adjust the settings according to your respective environments:

General Page:

Database Page:

The key things here are (and really remember this) you must:

• Ensure that the paths to the DB files are the same as they were on the cluster
• Ensure that the “Do not mount this store at start-up” and “This database can be overwritten by a restore” tick boxes are checked.

Restoring from backup:

Ok, this is the part where we use those logs and database backups from the first stages of this article – therefore you will need to copy the .bkf file back to your Exchange Server to allow NTBackup to restore the data.

Rather than go through the entire restore process here – I have provided you with a video which details the restoration process below:

(as always you will need either WinRar or 7–Zip to open the contents of this file)

RestoringFromBackup.rar [395KB – Compressed] – [26MB – Expanded]

What is in the video? – well the video will cover the following elements (unfortunately with no sound):

• How to catalog the backup file
• How to select the relevant files to restore
• Will show you a “Before and After” look at the folders that you have created

When you have restored from backup we are ready to move on the the final stage of this process.

Mounting the Databases and Reconnecting Mailboxes:

Right – before you charge right in there and mount all of the databases and get ready to celebrate – there are a few more steps that need to be followed.

I found that when I restored my databases and then used the Exchange System Manager to run the “Mailbox Clean Up Agent” (accessed via navigating to “Administrative Groups->First Administrative Group->Servers->->->”) then expanding the database tree to display the “Logon, Mailboxes, and Full Text Indexing” – then right clicking on the “Mailboxes” entry and then from the context menu that appears choosing “Run Clean Up Agent” – the list of mailboxes would change from all entries in a “Connected” State to all mailboxes in a “Disconnected” State (the video depicts this).

When I saw this I thought “bum” – however upon investigation I stumbled upon the answer.

From what I can make out, as we did not use the /DisasterRecovery switch during Exchange Setup – a default store was created. Now for some weird reason every account in Active Directory had the following values modified to claim that their mailbox was in the default store (which of course they are not):

• homeMDB
• homeMTA – although in fairness this value on each of my users reflected the GUID of the clustered Exchange server that I deleted

The good news however was that, the msExchMailboxGuid was intact (I found this out as I tried to reconnect one of the mailboxes from the ESM and it gave me an error message telling me that the mailbox was already connected).

So, what does one do in this situation? – Answer: write a script of doom to correct the issues.

If you experience this problem you will need to download the following script to your Exchange Server:

resMB.vbs

Requirements of the Script:

• You MUST ensure that ONLY ONE mailbox store is mounted at any one time – this is to do with the parameters that the script accepts and the way in which it executes.
• The script REQUIRES three parameters 1) the directory path to the store that you are working on 2) the directory path to the Exchange Servers MTA 3) the path and filename of a log file

Limitations of the Script:

• Mailboxes that contain ‘ will be skipped

Therefore syntactically the command line for the script looks like this:

cscript.exe resMB.vbs “” “”

– therefore an example command line is:

cscript.exe resmb.vbs "CN=GEN-POP-DB,CN=SG2-GEN,CN=InformationStore,CN=LAB-EX-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=LAB,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=lab,DC=com" "CN=Microsoft MTA,CN=LAB-EX-01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=LAB,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=lab,DC=com"

You can obtain the directory paths mentioned above from ADSI edit – however please review the following video which provides you with a visual account of how the script works and what you need to do to correctly run the script. Also in the video you will see and example of the “Run Cleanup Agent” issues that are caused after the restore.

PostRestore-Mount-Script-PT1.rar [838KB – Compressed] – [60.7MB – Expanded]

When you have run the script WAIT 10 minutes and then restart the MSExchangeSA service from the “Services” command applet, then you will need to mount the store that you have been working on and then run the “Clean Up Agent” again. – below is a video detailing these steps:

PostRestore-Mount-Script-PT2.rar [426KB – Compressed] – [33.5MB – Expanded]

Repeat the process for any other Databases that you may have (remember that you MUST close down a fixed database if you wish to work on another – the script must ONLY work against one Database at a time).

When you are done (or in the case of my lab I was done) – I now had a fully functional Basic Exchange installation – all converted from a Cluster.

(I really need to get out more! )