Clean installing 24H2 without getting all cumlative updates slowing you down.

Due to an annoying change in oobe, Windows now automatically downloads all cumulative updates during installation at the oobe phase regardless if using an MS or local account. This can take easily take tens of minutes.

The easiest way to avoid that is to create a local account (by your favourite method) with the internet switched off.

If installing in Hyper-V, you just turn off the network adaptor before installation.

This is much faster, avoids all those tedious oobe screens and does not hold you up installing all the cumulative updates - you can do that later once it is installed.

Once installed, turn on the internet (or turn on network adaptor in Hyper-V), then optionally search for updates.

I assume you can turn off the network in other VM Tools as well if using them instead of Hyper-V.

i linked this post to another post as a possible answer, i hope you dont mind.

best of luck, Steve ..

If one could block access to sdx.microsoft.com early in the OOBE process, e.g. by adding an entry to the hosts file pointing to 127.0.0.1, this update process would fail gracefully. I don't mess with unattends very much. Maybe @hsehestedt?

Edit: Actually, not so gracefully. OOBE complained that I had no network connection a few times. I just kept telling it to retry, and it went through.

pseymour said:

If one could block access to sdx.microsoft.com early in the OOBE process, e.g. by adding an entry to the hosts file pointing to 127.0.0.1, this update process would fail gracefully. I don't mess with unattends very much. Maybe @hsehestedt?

Click to expand...

I’d like to see that added to Rufus. MAKE IT HAPPEN SEMOUR! FEED ME!!!

I'll need to experiment with this because this is news to me, but I have some initial thoughts:

First, I typically do unattended installs and because I also always inject the latest updates into my images, when I install, I already have all the cumulative and incremental updates in my image so I never see this. That's why this is completely new to me.

Here is what I will try: First, I'm going to try an unattended install of an older build to see if that gets around it downloading updates during installation.

Second, I'm curious about exactly where it tries to get the updates. If it is sometime AFTER the first initial static screen following the reboot(s) during setup, I wonder if you couldn't simply press SHIFT + F10 to open a command prompt and do an "ipconfig /release" to make sure you have no network connection.

Let me start testing and I will report back.

If anyone has additional ideas I should test, let me know.

Okay, testing done.

For an unattended installation it does indeed look for updates, so that alone does not work around the issue.

For a standard manual installation, it only looks for the updates several screens into the OOBE so you can simply do an "ipconfig /release". If you want to create a local account you can do this:

At the first static screen during OOBE (Is this the right country or region?), do your usual SHIFT + F10, oobe\bypassnro. The system reboots. When you get to that same screen again, do a SHIFT + F10 again and issue the "ipconfig / release".

Question: What exactly is it downloading here? When I see it checking for updates it is extremely fast, just a few seconds. Is it only grabbing some sort of critical updates for setup only? Are the long updates only happening in insider builds?

My test scenario:

I was testing with build 26100.1742. That already includes the Checkpoint update, but not any incremental update, so if it was indeed downloading an incremental update, it would take longer. Also, when setup is done, I am on build 1742, not anything newer, so clearly it is not installing the incremental.

Help me understand

EDIT: I'll research more to see what can be done to work around this. If I can disable network with a registry entry, in the same manner as the entries to bypass system requirements, then we would be in business. Starting research now

Okay, if my research is correct, this should be easy and Pete could incorporate this in Rufus super easily.

Apparently, when you run "oobe\bypassnro" that IS already disabling the network (NRO = Network Readiness Operations). So, if you do that, then there is no need to do the ipconfig /release after the reboot.

This can also be added to the registry during setup so that it would be just one more entry in addition to those that bypass requirements.

This is all what the web tells me - I have to actually test it.

As they say, "please standby".

Wow, the registry entry I found made it worse. It actually triggered the installation of updates that you described.

It first showed me this screen from which I selected to setup for personal use:



Then I get this:



This is the first time that I have ever seen this.

More research. I have a feeling that this time I won't be so quick - this one will probably take a while of research and testing.

BypassNRO does nothing to disable the network, it only works on MSA enrollment.

"ENROLL" -> "N" -"RO"
If you're fluent in English, read that word out loud to make sense of the inside joke.

Prior to 24H2, W11 OOBE always had Zero-Day Patching (ZDP) but it was always limited to minor fixes like OOBE updates. In 24H2, OOBE is forcing a WU update to the latest CU if your install is behind. You're more likely to see this if you didn't integrate the Setup Dynamic Update into the install image.

garlin said:

BypassNRO does nothing to disable the network, it only works on MSA enrollment.

"ENROLL" -> "N" -"RO"
If you're fluent in English, read that word out loud to make sense of the inside joke.

Prior to 24H2, W11 OOBE always had Zero-Day Patching (ZDP) but it was always limited to minor fixes like OOBE updates. In 24H2, OOBE is forcing a WU update to the latest CU if your install is behind. You're more likely to see this if you didn't integrate the Setup Dynamic Update into the install image.

Click to expand...

Thanks, Garlin. Yeah, I discovered in my testing that the bypassnro does not bypass networking.

I guess that the reason I never saw this was that I was always using a minimum build of 26100.1742 which already has the cumulative update. What you say makes sense - since it only updates to the latest cumulative and not incremental, this is why I was not seeing it triggered.

I really appreciate your insight - that helps me understand a lot.

Ironically, I found a registry setting that I added to phase 1 (WindowsPE) that basically is the equivalent of running bypassnro and that in turn caused me to see that update screen for the first time ever (as I showed in my earlier screenshot), so that was a negative on success.

For now, the only real workarounds I see are:

1) During a manual setup, use the ipconfig /release.
2) Inject the latest updates into your image so that Windows has nothing to update

I already do #2, so this is pretty much a non issue for me, but I will continue the research.