WSS v3 Search - Can't remove server from farm

[ThaPCdoc]

Last month, our SQL server died and we had to restore from backup to a new SQL2005. Since that time, the search has not worked right, so I am in the process of reconfiguring and reindexing. However, any time I make ANY changes in the CCM, I get the following error:

--------------------------
An update conflict has occurred, and you must re-try this action. The object SPSearchServiceInstance Parent=SPServer Name=IIASERVER3 is being updated by INFOINTL\WSS-SVC, in the OWSTIMER process, on machine IIASERVER3. View the tracing log for more information about the conflict.
--------------------------

This is odd, mainly because ther server IIASERVER3 has been pulled from the farm, and WSS3 has been uninstalled.

I get this error even when I go to Operations > Services on Server, and try to REMOVE SERVER. IIASERVER3 is still listed as being a search service. Currently, the WSS_SEARCH_<machinename> databases are all offline in hopes that it will rebuild, but without being able to delete the indexes either from CCM or STSADM, I cannot do an index rebuild.

Is there a way to FORCE this server to be removed from the farm? (btw, I get the exact same error when running STSADM -o spsearch -action stop from ANY server)

My farm consists of
1 Public WFE
1 DB Server (SQL 2005 Std)
1 Internal WFE (IIASERVER3, which I'm trying to remove)

 

[ThaPCdoc]

I FOUND MY OWN ANSWER!! I have to post this because I litterly spent 4 days looking for a solution to this, and I truely hope this helps anyone else with similar issues.

After fixing the problem, I recreated it by starting a timer job on another machine, and shutting it down in the middle of the operation. All other servers in the farm think that the powered-down machine is still in the process of updating a DB using a timer job. Deleting the cache (as mentioned below) is the absolute solution. My God, I can't believe it was that simple.

http://www.eggheadcafe.com/software/aspnet/30460975/updatedconcurrencyexcepti.aspx

And if the link is dead, here is the solution as posted by Wei Lu from Microsoft:

02-Aug-07 10:38:31

------=_NextPart_0001_3E54A185
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hello JJ,

I found that this issue is caused by a disaster recovery. The file-system
cache on the front end is newer than the contents of the configuration
database. After a disaster recovery, it may be necessary to manually clear
the file system cache on the local machine.

Resolution
=============================
Clear the file system cache on all servers in the farm running the timer
service manually. To do this, stop the timer service, delete (or move) the
contents of the folder at
%ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<someGuid>

Then, simply restart the timer service. The cache will be rebuilt and the
issue should disappear. This should be done on every machine in the farm
running the timer service

Hope this helps!

Sincerely,

Wei Lu
Microsoft Online Community Support