4 ms·

One of the core issues with breaking this pattern is that you're installing a new feature on this reboot, then installing all of its patches on the next reboot.

One of the core issues with breaking this pattern is that you're installing a new feature on this reboot, then installing all of its patches on the next reboot. So you install 186 updates on a fresh install. This includes .NET 4.5 (or 4.5.1 or 4.5.2), and requires a reboot. Now you're done right? You just installed 168 updates, how many updates can there be? On your next reboot, you get another 60 updates, of which 20 are .NET 4.5 updates and security updates. Another is the OS SP1, which needed a reboot before install. Now you're done right? You just installed 228 updates, how many updates can there be? On your next reboot, you have another 168 updates, most of which are patches for OS SP1. Now you're done right? You just installed 396 updates, how many updates can there be? On your next reboot, you have another 12 updates, including... I've seen this chain across more than 6 reboots. I once literally spent an entire day just patching a server.

tomswartz07 12y ago
Yep, this is exactly what I'm talking about. I don't see why they cant 'look ahead' to say; Oh- this update X depends on update Y, but it's going to be installed, so we could just add it in the queue anyway.
- bentcorner 12y ago
  Or rather, slipstream future updates to current downloads. E.g., if you're installing component X that has patches A, B, C, then perhaps you should get customers to download component X that is already in a patched state.
  - whoopdedo 12y ago
    What I always wonder, while twiddling my thumbs during the interminable upgrade-reboot-upgrade cycle, is how many of these these updates will be overwritten by a later update. Am I wasting my time downloading multiple versions of the same file?
    - UweSchmidt 12y ago
      These upgrade-shortcuts could introduce a significant increase in testing complexity if you want ensure that you can go from any system version to the current version. On the other hand, with the current system people upgrade from Windows 1.0 to 8 (e.g. https://www.youtube.com/watch?v=8WP7AkJo3OE https://www.youtube.com/watch?v=8WP7AkJo3OE).
    - Guvante 12y ago
      Unfortunately the update reboot cycle is incredibly reliable, which is why it has persisted. Can't beat "millions of machines have taken these steps". Thoroughly agree that a more simplified method would be awesome though.
  - stephengillie 12y ago
    That's the kind of functionality I expect from Windows Deployment Services.
kristopolous 12y ago
that was decent work. Good job - really accurate.
- stephengillie 12y ago
  I'm going thru the process as we speak. :)
  - tacticus 12y ago
    I use the powershell script from the packer winrm project. it's ugly as sin and requires many many reboots (and is slow as fuck) but at least it gets them all installed.
acdha 12y ago
This is also compounded by how long those updates take because they somehow managed to make writing files to disk a CPU-bound process at some point in the mid-2000s. If you have 50MB of updates to install on any other operating system it will take a few seconds but on Windows XP+ it will run at a few hundred KB/s while using 100% of a CPU which can run SHA-512 at well over 1Gbps.
neckro23 12y ago
You can skip maybe half of this by installing the Service Pack manually right away. It still sucks, but not quite as much. No idea why Windows insists on installing individual updates before the Service Pack that includes them all anyways...

tomswartz07 12y ago

Yep, this is exactly what I'm talking about. I don't see why they cant 'look ahead' to say; Oh- this update X depends on update Y, but it's going to be installed, so we could just add it in the queue anyway.

bentcorner 12y ago
Or rather, slipstream future updates to current downloads. E.g., if you're installing component X that has patches A, B, C, then perhaps you should get customers to download component X that is already in a patched state.
- whoopdedo 12y ago
  What I always wonder, while twiddling my thumbs during the interminable upgrade-reboot-upgrade cycle, is how many of these these updates will be overwritten by a later update. Am I wasting my time downloading multiple versions of the same file?
  - UweSchmidt 12y ago
    These upgrade-shortcuts could introduce a significant increase in testing complexity if you want ensure that you can go from any system version to the current version. On the other hand, with the current system people upgrade from Windows 1.0 to 8 (e.g. https://www.youtube.com/watch?v=8WP7AkJo3OE https://www.youtube.com/watch?v=8WP7AkJo3OE).
  - Guvante 12y ago
    Unfortunately the update reboot cycle is incredibly reliable, which is why it has persisted. Can't beat "millions of machines have taken these steps". Thoroughly agree that a more simplified method would be awesome though.
- stephengillie 12y ago
  That's the kind of functionality I expect from Windows Deployment Services.

kristopolous 12y ago

that was decent work. Good job - really accurate.

stephengillie 12y ago
I'm going thru the process as we speak. :)
- tacticus 12y ago
  I use the powershell script from the packer winrm project. it's ugly as sin and requires many many reboots (and is slow as fuck) but at least it gets them all installed.

acdha 12y ago

This is also compounded by how long those updates take because they somehow managed to make writing files to disk a CPU-bound process at some point in the mid-2000s. If you have 50MB of updates to install on any other operating system it will take a few seconds but on Windows XP+ it will run at a few hundred KB/s while using 100% of a CPU which can run SHA-512 at well over 1Gbps.

neckro23 12y ago

You can skip maybe half of this by installing the Service Pack manually right away. It still sucks, but not quite as much. No idea why Windows insists on installing individual updates before the Service Pack that includes them all anyways...