WSS 3.0 Update -> Sharepoint 2010 Foundation, or the right path to Disaster Recovery

I recently had to update WSS 3.0 on Sharepoint Foundation 2010. I want to share my experience, as well as talk about the problems that Microsoft "hides" from us.
Preface:
Windows Sharepoint Services was installed as a stand-alone server, using the Windows Internal Database Engine. I want to upgrade the farm to the Sharepoint 2010 Foundation. The rest is under the cut. Who is interested in the final working procedure - in the lower part of the article.

Microsoft provides a complete (as it seems at first) guide to this procedure here .

In short, Microsoft offers the following procedure:
1) From the Sharepoint 2010 Foundation disk / distribution install all necessary software (prerequisites)
2) Install Sharepoint 2010 Foundation
3) After installation, select the update of the existing WSS 3.0 farm
4) Done.
It is a pity, but everything is not so simple.

The description of supported / unsupported upgrade paths states that the Sharepoint 2010 Foundation does NOT support the Windows Internal Database Engine. Then the first thing that comes to my mind: install on SQL Server Express 2008 server and specify it when upgrading.
ATTENTION! The SQL server must be of x64 architecture, on the x32 Foundation base installer refuses to deploy.
')
Actually, I am doing this, but it turns out that it is IMPOSSIBLE to change the SQL server when updating. In the Sharepoint 2010 update window, the Windows Internal Database server is selected, the installer successfully starts the update and gets an error saying that it does not have enough rights on the SQL server. Well, strange ...

In this case, the installer "kills" the farm WSS 3.0. Further actions, both using the administration portal and using the stsadm utility, are absolutely impossible.

How to recover from WSS 3.0? I decided to restore WSS 3.0 immediately to the SQL server in order to try In-Place Upgrade again:
1) Using the SQL Server Management Studio snap-in, we connect to the Windows Internal Database and backup the SharePoint_Config and SharePoint_AdminContent_xxxx-xxxx-xxxx-xxxx-xxxxxxxxx databases (these are the two bases WSS uses to store the settings). I just detach the database with the content (the name WSS_Content by default).
2) Next, I reinstall WSS (delete, re-install, put all Service Pack). During the installation, I specify the SQL server instance (in advanced mode), not the Windows Internal Database.
3) After the installation and upgrade is complete, I stop WSS 3.0 services, connect SSMS to the SQL instance and watch 2 databases there: the new SharePoint_Config and SharePoint_AdminContent ... I don’t need them, so I safely remove them and deploy the backups of these databases to the SQL instance (in My case is SQL Server Express 2008 R2).
4) Start the WSS service. In this case, WSS works fine, as before.

It seems that it can be updated, now there will be no problems, nevertheless, after all, on the SQL server. I once again run the WSS Update Wizard -> Sharepoint 2010. And, lo and behold, now the SQL instance is listed in the wizard window. I click "Next" and ... again swears at the lack of rights in the Windows Internal Database instance. “How ?!” I think. So, besides everything, WSS stores the name of the server / instance somewhere in the database.

After a few queries I found the table and rows where it is stored: the base SharePoint_Config, the table dbo.Objects.
With the following query, we can change this data:
USE [SharePoint_Config]
ALTER TABLE dbo.Objects
SET Name='NEW INSTANCE NAME'
WHERE Name='OLD INSTANCE NAME'
SET Name='NEW SERVER NAME'
WHERE Name = 'OLD SERVER NAME'

Re-run the wizard update. And, hooray, the first step successfully passes without errors related to the base. But, unfortunately, in the second stage, I get the error ERR Exception: System.ArgumentException: Error during encryption or decryption.
The solutions given in this KB from Microsoft do not help. The options I found on the Internet (removing the Administration Portal node in IIS, removing the App Pool in IIS) does not help.
I make the decision to deploy everything anew, by the method of detailing the bases, and not by In-Place Upgrade.

To do this, I again restore the WSS server using the procedure described above and:
1) I save all settings of Sharepoint sites (in my case it’s 1 site ).
2) Now I delete the WSS and put a “clean” version of it (only steps 1 and 2 of the above procedure).
3) Delete SharePoint 2010 Foundation
4) I do a rebut
5) Re-install the SharePoint 2010 Foundation in Stand-alone mode. After the installation is completed, the installer offers me to update the existing (“clean”) WSS farm - I agree. This time the update takes place without problems.
6) In the SharePoint 2010 Foundation Central Administration I create a site with the settings that I recorded in step 1. I ask the wizard to use the existing IIS site Site (which was created in WSS). As a content database, I specify a new database on a SQL instance (WSS_Content_Temp), which I will delete later.
7) Attach the WSS_Content database to the SQL server.
8) For this manual, I update and attach the database with content to the SharePoint 2010 Foundation team:
cd “C: \ Program Files \ Common Files \ Microsoft Shared \ Web Server Extensions \ 14 \ Bin”
stsadm –o addcontentdb –url site –databasename WSS_Content –databaseserver NEWSERVER \ NEWINSTANCE
9) The upgrade process is underway. After it, I delete the WSS_Content_Temp database from the site in SharePoint Central Administration.
10) Voila.

In general, 2 things are not clear to me: why does the installer not check the necessary requirements and produce errors that do not correspond to reality? But it is rather a rhetorical question ...