Hello Sean
thanks for your response. I have read some of your books and Pdfs :-)
yes, that UWF gets messed up because of changed physical driver numbering is my assumption too.
The drive C is the only drive which is protected by UWF. And it always got the letter C.
The overlay type is RAM.
But with a tip from one of my colleague we were able to solve this issue for us at last.
I think UWF provides an option for such cases when physical driver numbering changes, SetBindByDriveLetter.
This option is not available with uwfmgr.exe but with wmic only (so far as i know currently).
With this program, WMIExplorer, the option was tested. Setting the property to false has solved this issue. The physical drive numbering still changes as described before but the C: drive is protected in both boot configurations now (boot with and without drives).
It was somewhat difficult to set this option with scripting. As we have a workflow proposed by one of your documentations the creation of the "golden" image is heavily scripted for several reasons (you know which :-)).
Here is a snippet from our powershell script setting this option:
$COMPUTER = "localhost"
$NAMESPACE = "root\standardcimv2\embedded"
$uwfOverlayDriveC = Get-WmiObject -Namespace "root\standardcimv2\embedded" -Query "SELECT * FROM UWF_Volume WHERE CurrentSession=false AND DriveLetter='C:'"
$isTightBindingEnabled = $uwfOverlayDriveC.SetBindByDriveLetter($false)
$uwfOverlayDriveC | select-object -Property BindByDriveLetter
Using this script during the first OOBE sets the option to false. Then sysprep is made and in the next OOBE boot the filter is enabled. And UWF shows expected values for consumption and available space for booting with and without the other drives.
So this issue is solved i think. But thanks again for your answer, Sean.
Greetings from germany
Falk B.