Saturday, August 8, 2015

Forcing a Windows 10 upgrade in an iSCSI environment

If you boot Windows machines from iSCSI, you should know that the Windows 10 Upgrade doesn't load iSCSI drivers and dumps you into a recovery environment. However, there is a way to get around that.

Once the Windows 10 recovery environment (Windows PE) boots, use the Advanced Options to obtain a command line.

To start the iSCSI initiator:
wpeutil initializenetwork
net start msiscsi
iscsicli qaddtargetportal portal.ip.address.here
iscsicli listtargets
iscsicli qlogintarget iqn.xxx.xxx
iscsicli PersistentLoginTarget T * * * * * * * * * * * * * * * 0 (that was fifteen * characters)
iscsicli ListPersistentTargets
iscsicli ReportTargetMappings
Once this is ready, you can manually install Windows 10:
 c:\$Windows.~WS\Sources\Windows\sources\setuperror.exe
For reference, here are the hidden upgrade folders and their meanings:
"Windows.WS = Windows Server Folder"
"Windows.BT = Windows Backup Files"
"Windows.Old = Windows backup files"

Have fun!

7 comments:

Anonymous said...

Hi Baitisj,

thanks for your recipe, sadly it does not fully work here (upgrading from Win8 32 Home on an iSCSI volume).

This command complains that I already have a connection to the iSCSI target

iscsicli PersistentLoginTarget T * * * * * * * * * * * * * * * 0 (that was fifteen * characters)

so the following one tells me I have no persistent targets and my system does not have

c:\$Windows.~WS\Sources\Windows\sources\setuperror.exe

I only have

e:\$Windows.~BT\Sources\setuperror.exe

but it does nothing, it does not even show a window or some message on the console.

BTW, unit e:\ is the iSCSI volume from which the upgrade started (using Windows Update).

If I start

e:\$Windows.~BT\Sources\setup.exe

I'm offered the standard installation window which does not accept my iSCSI volume.

Do you have any other trick up your sleeve?

Regards.

M.

baitisj said...

Hi M.:

It looks to me like your system's Windows 10 installation got "rolled back," and you lost the Windows.~WS directory.

I'm not sure why this happened.

Hopefully this is enough of a tip to get you going again.

-JB

Anonymous said...

I have the same problem. After running the iscsi commands the drive letter appears but \$Windows.~WS is not there. Is there a missing step like breaking out of the boot early instead of waiting for it to fail?

Anonymous said...

After struggling with an upgrade of an ISCSI boot version of Win 7 to Windows 10 for days, the solution was to do a physical disk install of Win7 via a SATA drive, followed by a Windows update upgrade to Windows 10, and then copying the results back to the ISCSI disk. I used Paragon Migrate for the last step. I now have a version of Windows 10 properly activated and booting from my ISCSI NAS drive.

It took days to get here. Thanks for the clues above. This blog was most helpful.

Kenton Varda said...

In my case, $Windows.~WS exists but it does not contain Sources\Windows. It contains Sources, which has a file called SetupHost.exe and a subdirectory called "Panther" (containing nothing interesting), but no "Windows" subdirectory.

There is a $Windows.~BT\Sources\setuperror.exe, but it won't run claiming "The subsystem needed to support the image type is not present" -- presumably it needs WoW64 which isn't available in WinPE, or something.

Any other hints?

baitisj said...

Hi Kenton. I think that I may have to resign myself to the answer of, "not really." Apparently I did something that I didn't document. Although this post offers "clues," I guess I don't have a comprehensive answer, as illustrated by your comments and that of "anonymous" above.

Incidentally, since this post was made, I upgraded my hardware and sold off the workstation that I used to boot off of iSCSI. I now use virtual machines for most everything, including the Windows 10 machine that used to boot from iSCSI.

One thought:

You might be able to iterate more quickly by having a VM boot from a local iSCSI device.

Good luck. Would love to hear if you figure out the missing pieces.

Laurence Perkins said...

In my case, the files all appear to be there, but they have the wrong drive letter, so they refuse to run because (guessing by the error message) they use hard-coded paths. :(