I recently spent a lot longer than expected trying to get a Windows 11 23H2 installation to update. This was after many attempts at scripted updates which kept failing. Not my usual subject matter for this blog, but having spent a long time on it, I wanted to document it.
Scenario I was faced with:
- Needing to in place upgrade to Windows 11 25H2 due to a LOT of specialist software on the machine.
- Multiple attempts using various methods, such as Windows Update Assistant and an ISO install had failed
- Logs indicated a BitLocker issue
- Even after removing BitLocker, subsequent failures logged SAFE_OS / MIGRATE_DATA stage.
Step 1 - The BitLocker problem.
This is fairly common — once I had looked at the logs and confirmed BitLocker was involved, it was straightforward to fix.
BitLocker issues are usually one of:
- Active in a way setup doesn't like
- Mid-state - such as a suspension not applied correctly.
- Tied to something with the TPM chip or a change during the upgrade.
Check the status with
manage-bde -status
Protection was still active, so I suspended it:
manage-bde -protectors -disable C:
Confirmed of course:
manage-bde -status C:
Tried the upgrade again, still failed, so I decrypted the drive:
manage-bde -off C:
Still failed, but with a different error - so progress was made.
Step 2 - Persistent Upgrade Failures
With Bitlocker neutered, the upgrade still failed.
I tried a couple of techniques at this point:
- Fresh download, as the one I was using was from last year and there had been reports that the original ISO release had a problem.
- Copying the installation files locally.
Usually I would have wiped the machine by this point. However the client informed me that there is between 12 and 18 hours of setup time on this machine, plus the cost to get someone to do it, so I was being strongly discouraged from the wipe option.
At this point, I turned to AI, as it was a more complex problem than anything I had seen before. The logs went in to AI to see if it would make any suggestions.
AI immediately pointed to the migration phase (SAFE_OS / MIGRATE_DATA), and as there had been a problem with BitLocker earlier, that something with the TPM configuration was the most likely cause. AI was also able to confirm that a lot of the log was noise which I had been ignoring and was right to do so.
AI said that these four elements were the key indicators:
• 0x8007042B
• Result: 44
• V2VArbitrate
• "script" attribute is mandatory
Pointing to a migration engine failure. That kind of made sense.
There was a fair bit of back-and-forth while I got it to justify the conclusion - I needed to be confident before trying something this invasive and be aware of the consequences if it didn't work.
Satisfied that the solution it was suggesting was worth a try, I did the following:
1. Copied the Windows 11 ISO to the local machine.
2. Within the ISO files, I renamed the file tpmdriverwmi-replacement.man in the sources\replacementmanifests directory so it wasn't used during the setup.
Then as a further step, I cleaned up the previous upgrade attempts, as the logs had been showing some errors. This was a little more involved than expected.
rd /s /q C:\$WINDOWS.~BT
rd /s /q C:\$WINDOWS.~WS
Fairly obvious ones, not always present.
Sometimes a permission fix was required:
takeown /f C:\$WINDOWS.~BT /r /d y
icacls C:\$WINDOWS.~BT /grant Administrators:F /t /c
(I got very good at this by the end).
Then there is a registry key - learnt this one the hard way.
reg delete HKLM\SYSTEM\Setup\Upgrade /f
That often requires a ownership/permissions change to get it to all remove.
That still didn't do it.
The final fix was to actually remove the reference to that file from the OS:
Using an elevated command prompt:
notepad C:\Windows\WinSxS\migration.xml
Then searched for
microsoft-windows-tpm-driver-wmi
And removed the entry for it, including the <file> and </file> elements - of course a backup of the file was taken before editing!
After all that, running setup.exe without updates the installation went through.
I counted nine upgrade attempts, each taking two hours, so this went on for over two days. Fortunately the end user didn't need the device as it was used for sporadic specialist tasks, so I was able to keep plugging away.
Easily the most complex upgrade I have done, which just a few years ago I wouldn't have been able to resolve - I simply wouldn't have found that issue without AI.
