Quick Tip – Removing Exchange 2010 from a former DAG member after a failed SP1 Upgrade…

I have been playing around with Exchange 2010 more and more recently (some of you will probably be thinking either about time, or indeed I am very far behind!) and during such research came across an interesting little problem on one of my Multi Role Exchange Servers (MBX, HT, and CAS) when trying to remove Exchange 2010.

There server was running Windows 2008 R2, and had previously been part of a LAB Database Availability Group configuration – which I believed that I had removed sometime ago, and I now wanted to upgrade it to Exchange 2010 SP1.

In essence the upgrade from the RTM to SP1 went wrong (I will not go into the detail of exactly what happened, suffice to say I think the whole install on this node has been suspect for a while) so I decided to remove Exchange from the server completely and start again rather than waste time and nurse it through its problems – the idea here being that I would go straight to Service Pack 1 on a fresh install.

I set about uninstalling Exchange 2010 from the Node in the usual way – via Programs and Features –> Exchange Server 2010 –> Uninstall, however this is where my problems started as I was at first presented with the following error message;

unist001

I suspected that this was due to the Watermark registry entries which Exchange setup and any Service pack places within the registry so I jumped into the Windows registry and navigated to the following key: [ HKLM –> Software –> Microsoft –> ExchangeServer –> v14 ] and within each of the installed roles (e.g. Client Access Role) I removed the “Action” and “Watermark” keys – additionally I also removed the “Setup-Save” key – see below

unist002

This was enough to solve the initial setup error – however during the Mailbox server prerequisites analysis I was presented with another error which claimed that the server was a member of a cluster and needed to be removed from a database availability group – see below

unist003

Now this was interesting, as whereas the server had previously been a member of a DAG, the DAG and all members therein had been deleted, and I could find no record of it still existing in ADSI or the Windows registry.

I pondered this for a bit, and came to the conclusion that this error might be caused because the failover clustering service was still installed on the Machine – therefore I decided to remove that.

Attempting to remove the Failover Clustering Service from the Machine failed (you can probably imagine that this was now getting a little frustrating) reporting that the server was still a node within an existing cluster (which is wasn’t any longer) – so I decided to try to setup a new cluster (via the Failover clustering manager) in the hope that this would allow me to perform a clean removal – only to receive the error message below

unist004

I can only assume that the mess that I was in was down to perhaps me not paying attention to a step when I removed the DAG (or this particular node was offline – I cannot remember now), which in turn led to the original cluster not being cleaned up correctly.

This left me stuck – I could not remove Exchange because it believed that the server was a member of a cluster, and I could not remove the cluster service as it believed that there was still a cluster that it was joined to – bugger.

After some further thought a moment of inspiration hit me (they are rare these days) – I dropped to a command line and typed in the following command:

Cluster.exe node /force

This reported that the command completed successfully – so I tried to remove Exchange again – guess what – it worked this time around!"

Going forward the best practices for me (or anyone else for that matter) would be to ensure that all clean ups are completed before attempting to uninstall Exchange (and also ensure that all nodes are on-line when removing / moving cluster resources) – but I hope that this will help somebody out along the way.

Sharing is caring!:

4 thoughts to “Quick Tip – Removing Exchange 2010 from a former DAG member after a failed SP1 Upgrade…”

  1. Got the same issue with Exchange 2013.
    If the Exchange is the last node in the Cluster the Cluster must not stopped.
    Cluster node /force
    Thank you man!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.