Solved (Needs Confirmation) I think Microsoft just disabled bringing up CMD during OOBE phase of Windows installation

I actually used my manuel from a few years ago, where i made a note that it must be disconnected, otherwise the shift+f10 did not work. So this behaviour is not new in this version.
Anyway the confirmation is made.

Tester said:

Anyway the confirmation is made.

Click to expand...

now that three of us confirmed the issue, I reported it to Microsoft.... let's hope they fix it soon......and thanks for taking the time to test

Just to be clear. For me nothing have changed. All is how it used to be and used to work for the past few years. Two confirmation it don't work. And from me a confirmation, that all is still working like it how it used to work.

Okay, I did some further testing with 4484 and here are the results:

Whether networking is enabled or not is irrelevant. In either case, the first time that I get to the screen where I am asked to confirm the language, SHIFT + F10 will not work whether the network is enabled or not.

The trick is to simply force a reboot at that screen. You could power off / on, hit the reset button, whatever you need to do to reboot. After the reboot you will again end up at the same place and this time SHIFT + F10 will work. Again, it matters not one bit whether networking is enabled or not.

hsehestedt said:

SHIFT + F10 will not work whether the network is enabled or not.

Click to expand...

If you booted with network, and then disconnect, then try to do Shift+f10 then it does not work, as it was already detected as connected.
Need to unplug it during the instal before its restart and shows the language screen. I did not have to reboot the system that way to get Shift+f10 to work.

Follow-up: While it does not matter whether networking is enabled or not to get the command prompt, it still does matter for the purpose of being able to create a local user account using this method. Before you run OOBE\Bypassnro from the command prompt, ensure that the network is disabled. If you do not do this, then you will not be able to create a local user account without signing into a Microsoft account during setup.

Tester said:

If you booted with network, and then disconnect, then try to do Shift+f10 then it does not work, as it was already detected as connected.
Need to unplug it during the instal before its restart and shows the language screen. I did not have to reboot the system that way to get Shift+f10 to work.

Click to expand...

I tried it on two VMs, and two physical machines and that is NOT how it works for me. Again, the state of the network matters not one bit on any of those tests. The only thing that I had to make sure of was that networking was disabled prior to issuing the oobe\bypassnro. I could have networking enabled right up to the moment where I am ready to run oobe\bypassnro. Having networking enabled until 5 seconds before running that command still works fine so long as I disable it just seconds before running the command. That works perfectly every single time.

And once again, it makes zero difference to being able to open the command prompt so long as you do one reboot.

Windows tracks an install's progress by updating a set of reg values. If there's a planned or unplanned reboot, it resumes the install at the last checkpoint.

This is how BypassNRO.cmd is designed to work. By the time you get to open a CMD shell, OOBE has gone past the bypass check. So the reboot in the script restarts OOBE in a location a little earlier (because the checkpoint isn't exactly in the same spot). And now the bypass value is processed.

So I'm not surprised that forcing a reboot makes Shift-F10 work again. OOBE is resuming at a spot, past whatever was disabling Shift-F10. The current state of Shift-F10 isn't a persistent value that's carried over on reboots.