Over the years I have seen this question arise more than once, and practically every-time someone will say no you cannot.
I started to think about this (a while ago now) as I wanted to understand why Microsoft have said it cannot be done, and why people are warned off doing it. I expected at first to hit a brick wall – with an almost immediate “oh that’s why moment” – but, as I persevered with my investigations – I got closer and closer to actually completing the task. Today however I have reached a point where I can say that I have managed to develop a conversion system that can be used to change a Active / Passive clustered EVS into a single node “Basic” installation.
In this article I would like to share the steps that I worked through with you, however before I begin I would like the following to be understood:
- The following article contains some very dangerous stuff in terms of Active Directory and Exchange – So don’t mess around with this in production – all of the work contained in this article was completed in a TEST LAB – I am not suggesting that anyone actually uses this in a real situation – and if someone wishes to – please note that I cannot be held responsible for anything that might happen.
- Microsoft will not support this in a million years – so be warned.
- This article assumes that you have a reasonable understanding of both Windows and Exchange based clustering.
After the above you might be thinking, well why write about it? – the answer to that is – even though I would not recommend ever doing this, the article itself does reveal some interesting things about how Exchange interacts with Active Directory, plus, there might be someone out there whom is looking for a way to clone a Cluster to a single instance in a test lab but is running up against problems as they have used a restored copy of their AD environment (you see more about why this is relevant).
Setting the scene:
In my test lab I have the following configuration:
- x 1 Domain Controller – Windows 2003 x64 SP2
- x 2 Cluster Nodes – Windows 2003 x32 SP2 configured as an Active / Passive Exchange EVS
- x 1 Front End Server – although this is not relevant for this article
- 389 Mailboxes with at least 1 mail item
When looking in Active Directory Users and Computers under the “Computers” container on the Domain Controller in my test lab I started out with the following Cluster based configuration – you can see a MSDTC Network Name instance (EX-MSDTC-NN), a Exchange Virtual Server instance (LAB-EX-01), and a pair of computer names which are the physical nodes that make up the cluster (x32EX-ND01 and 02) – like so:
The object of this process is to remove the MSDTC, and the node instances, but the EVS name will remain as a new physical server (rather than a clustered instance).
In addition to the computer accounts in my lab, there are 389 users accounts, all of which have a mailbox on the current EVS (LAB-EX-01) with at least one mail item within the mailbox (you will see more on this in a bit) – the reason why it is configured like this is:
- At the end of the process I want to be able to connect to a mailbox on the Basic Server, look at a mail item that was present BEFORE I converted it, AND still be able to send mail to other mailboxes.
On one of the Clustered Exchange nodes, when I opened up the Cluster Administrator (from Start->Programs->Administrative Tools->Cluster Administrator) the following Exchange Clustered configuration was displayed:
As you can see it is pretty straight forward for an Exchange 2003 two node Active / Passive configuration.
When opening the Exchange System Manager on one of the Nodes in the cluster you can see that I had the following configuration:
As you can see in the lab I had three storage groups default storage group each with one mailbox database (the public folders were contained in the default “First Storage Group”).
If I expanded one of the Mailbox Databases and clicked on the “Mailboxes” option the right hand information plane you change to look like the following:
As you see (and as previously mentioned) each mailbox contains at least one mail item.
Gathering Data About the Installation:
In order for this to stand any chance of succeeding the following criteria must be met by the “Basic” server which is created after the cluster has been deleted:
- The NETBIOS name of the server MUST be the same as the EVS virtual name
- The paths to the Storage Groups and Databases must be the same as they were on the shared storage of the cluster (this is done by assigning drives to the physical server with the same Letter and Folder Structure
Now the above were just a couple of things that I thought that I would need to know about the configuration of the clustered EVS, however I didn’t wish to be in a position after I had deleted the cluster computer accounts from the domain where I needed further information about the configuration. The situation I was in here was “how do you get information about something, when you do not know what information you will need?”
This is where the EXCHDUMP tool comes in to its own.
EXCHDUMP (which can be downloaded from here: http://technet.microsoft.com/en-us/exchange/bb288491.aspx (the tool is listed as ExchDump (English only)) is a small command line utility that you can run on your Exchange server that crawls your Exchange installation and posts all kinds of useful data about it into an XML file which can be rendered via a partner HTML file.
This tool not only reports on data such as paths to Storage Groups and Databases, but also provides information in regard to permissions, service pack levels and patches (just to name a few).
What I did here was download the EXCHDUMP tool to one of the nodes in my Exchange Cluster, I then extracted it to a drive, and then opened up a command prompt – where I ran the following command:
[Syntax: exchdump /SERVER:]
Upon hitting enter EXCHDUMP displays the following process information:
When the program has finished two files will appear in the directory where EXCHDUMP is installed one is an XML file, whereas the other is a HTML file – when you open the HTML file you will be presented with some very detailed information on your Exchange Server (as in this case I was) – below is a snapshot of the data generated:
The above information is useful when reconstructing the Exchange instance as a single server.
Backing up required data from the cluster:
At this point I am in a position to backup the data that I will need to restore onto the new Non-clustered Exchange instance – rather than go through the whole process here I have provided a video detailing the items that are needed – which can be downloaded from here:
In order to move to a non-clustered instance of your Exchange server all you need is a backup copy of the Exchange Databases and the Transaction logs.
Essentially the video above (no sound) gives you a brief overview of the physical structure of the transaction logs, databases and system path on the disk on my lab clusters. It then takes you through dismounting the Exchange Databases and then creating a .bkf file in Windows Backup on a local disk which contains all of the Databases and Transactions.
You will notice that the SYSTEMSTATE is not part of this backup – this is intentional – the system state will serve no use for what we are doing.
Just to make clear the backup file should contain every single database and transaction log (this can include .chk and .tmp files) from your Exchange Cluster which are attached to a Storage Group.
When the .bkf file is created it should be moved to a safe location on another server (as we will be trashing the server in the next step).
Removing the Exchange Cluster from your Organisation:
Ok, this is where it gets hairy – remember those backups in the previous step – are you sure you did them? – if not make sure that you have your databases and TS logs in the .bkf file – AND – the .bkf file has been moved from the Exchange Cluster that you are about to destroy and moved to a safe location.
I Shutdown down both nodes of the Exchange Cluster – and then jumped onto my Domain Controller and opened up Active Directory Users and Computers (ADUC) from Start->Programs->Administrative Tools.
When ADUC had opened I navigated to the “Computers” container and selected the MSDTC instance, Exchange Virtual server instance, and both nodes (this is done by holding down CTRL as you select) – I then right clicked on the last object selected and from the context menu that appeared I choose “Delete” – see below:
Now I as was using a VM Environment I then proceeded to delete the VMWARE files that made up the cluster (definition files, virtual hard disks) et al – however it is at this stage that if we were using physical boxes, we would be configuring one of the old nodes to be rebuilt as the non-clustered instance.
Rebuilding the Exchange server as a non-clustered Instance:
Ok, at this stage I created a new Windows 2003 Server (x32) and then joined it to my LAB domain – I ensured that it was given the SAME name as the previous clustered instance (EVS) – which was LAB-EX-01. (I have skipped the Windows build as I am assuming that most of you will be ok with this bit)
Now it is at this stage you need to configure your Disk Drives to the exact same specification as they were on the cluster – so for example:
- If your databases were on the shared storage assigned to a path of G:\EXCHSRVR\ – you will need to partition an identical path on the basic instance (this is important when you do the restore of the databases from backup later)
- The same rule as per above should be observed for the Transaction Logs
When you are happy that you Disk partitioning is an exact match to what it was previously you can proceed to the installation of Exchange.
Exchange Setup will Error:
When Windows is configured, and I was happy with the configuration of the server from a disk perspective and made sure that the NETBIOS name of the server matched the previous EVS network name I was in a position to run Exchange Setup.
So, I launched Exchange Setup (:\Setup\i386\setup.exe) and I was presented with the familiar looking Exchange Installer I clicked on Next (accepting the Welcome and the License Agreement screen) until I was presented with the Component Selection Screen – see below:
The first thing that I noticed is that under the “Action” column all that was …. so I tried to change it to “Typical” – see below:
When I selected the “Typical” option the following Error Message was displayed:
The Component “Microsoft Exchange Messaging and Collaboration Services” cannot be assigned the action “Install” because:
- The server object for the server (“LAB-EX-01”) is a clustered Exchange Virtual Server. You may not perform maintenance on this object from a stand-alone server.
- Cluster Admin should be used to perform maintenance on this Exchange Server.
Groovey – I thought, lets have a look at why.
Step 1 ADSI Edit:
Now, practically everything that makes Exchange work is in Active Directory, this includes entries and definitions for physical (and clustered Exchange Servers). So, it makes sense that Exchange setup is reading AD finding an entry for our previous cluster – and then balking at the fact that I am trying to install a basic instance – so the following is what I did to get around the error message above.
- On my new Exchange Server I downloaded and installed the Windows 2003 SP2 Support Tools (which can be downloaded from here: http://www.microsoft.com/downloads/details.aspx?familyid=96A35011-FD83-419D-939B-9A772EA2DF90&displaylang=en
I fired up my trusty copy of ADSI Edit and navigated to [Configuration,DC=,DC]->[Services]->[Microsoft Exchange]->[CN=]->[Administrative Groups]->[CN=First Administrative Groups]->[CN=Servers] – see below:
Here unsurprisingly I found an entry for the previous Exchange Cluster [CN=LAB-EX-01] – I right clicked on the entry and from the context menu that appeared I choose “Delete”
I then navigated to [Configuration,DC=,DC]->[Services]->[Microsoft Exchange]->[CN=]->[Administrative Groups]->[CN=First Administrative Groups]->[CN=Connections] – clicking on this entry in ADSI edit changed the right hand plane to look like the following:
Here there were a number of entries for the old Exchange EVS which I selected and deleted (as per above).
I was now confident that Exchange Setup would run correctly – so I ran :\Setup\i386\setup.exe again – and then went through the Welcome and License checks again but this time when on the Exchange components selection screen – when I selected “Typical” from the “Actions” column the view changed to look like the following:
I followed Exchange setup through to the end.
When Exchange Setup completed I performed the following actions:
- Applied Service Pack 2 for Exchange
- Applied all Exchange Patches since SP2
- Rebooted the server
Ok, so at this stage the following actions have been completed:
- The Exchange Cluster has been backed up and removed from Active Directory
- A new Exchange server which is non-clustered has been installed in the domain (but has the name name an same disk configuration)
In Part 2:
In part 2 of this article I will go through the following actions:
- Restoring the Databases and Transaction Logs
- Re-Connecting the mailboxes to the accounts in AD