Recently I was at a customer site who is using CCR & SCR for the replication strategy. The configuration has been going great and we have all the users routed through the Client Access Servers for OWA & Activesync.
With all this success, we were anxious to get started on our SCR testing. The client was a little worried about how SCR failovers would happen and of course nervous about losing data. Not to worry, we’ve done these failovers with a reasonable amount of success for a few years now….
Well halfway through the failover, we have the databases restored and try to take over the cluster…. and Boom!!! A Big annoying error pops up stating:
You must perform disaster recovery using the same version of Exchange as the last installed version. The current installed version is ‘188.8.131.52’; the last version installed is ‘8.1.291.2’
Alright fine… we can get through this. A quick google search and…. nothing :(
The problem is briefly mentioned in the some Exchange Blog Comments, an experts-exchange post, and some MSExchange.org forums. The problem of trying to move the CMS from the production cluster to the SCR standby cluster. Scott Schnoll mentioned a few months ago (July 2008 in a comment that this was a known issue)…. but no good details on the fix or the status. So I called Microsoft to get the details on the issue.
This problem comes up when actually running the command:
Setup.com /RecoverCMS /CMSName:<ClusterName> /CMSIPAddress:<IPAddress>
The tech on the phone informs us that this is a well known issue and is not going to be fixed until SP2 for Exchange 2007. This means RU4 & RU5 won’t contain the fix. The workaround is simple and hopefully won’t cause problems. The steps are as follows:
First we need to fix the version number of the machine account in Active Directory. To do this, we need to open up ADSI Edit from any computer in the domain and connect to the configuration naming context of the nearest DC to the Exchange Server.
Once there, browse to Services, Microsoft Exchange, <organizationname>, Administrative Groups, Exchange Administrative Group (FYDIBOHF23SPDLT), Servers, <ClusterName>
Now, Right+Click on the ClusterName, and open the properties.
When the properties box comes up, scroll down to find the attribute ‘serialNumber’, highlight the serialnumber and click the remove button. Then edit the text ,replacing “Version 8.1 (Build 30240.6)” with “Version 8.1 (Build 30291.2)”
If you are editing versions past RU3, the versions may be different; however, they will be called out in the error message when you run the /recovercms command. Essentially, the fix is to replace the serialnumber in ADSIEdit with the last build number called out in the error message (provided the serialnumber in ADSIEdit is in fact the first number called out in the error.
Once the updates are complete, don’t forget to click the add button and save the changes before closing out of ADSI Edit.
Hope this Helps!!